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ABSTRACT 


The  Joint  Deployment  System  (JDS)  forms  the  junction 
among  deliberate  planning,  time- sensitive  planning,  and  the 
deployment  cf  forces.  The  wmbccs  Intercomputer  Network 
(MIN)  supplies  the  necessary  intercor.nectivity  among  the 
joint  deployment  community  computer  systems.  In  January 
1982,  the  NfiNCCS  Information  System  (MIS)  modernization 
program  was  launched  with  objectives  including  the  acderni- 
zaticn  of  MHBCCCS  hardware  and  software  and  the  transfer 
from  the  present  MMSCCS  network  system  to  the  Defense  Data 
Network  (DDN) .  Because  of  provan  MIN  unreliability,  the  JDS 
required  site-unique  software  development  to  supplement 
present  MIN  software. 

Individualized  application  softwc.ra,  integrated  with  the 
improved  network  reliability  and  survivability  cf  the  DDN, 
will  enhance  the  present  C3  system.  This  thesis  demons¬ 
trates  that  the  total  implementation  of  the  Mis  involves 
additional  modifications  in  site-unique  applications,  stand¬ 
ardized  procedures  for  software  development,  updated 
hardware  technology,  and  a  multi-level  security  'system. 
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I.  IMTBODOCTIOl 


1.  POBPOSB 

In  the  late  seventies  time-frame,  the  Joint  Deployment 
Agency  (JCA)  experienced  an  satis  factory  HiSCCS  Intercoaputer 
Ketwcrk  (WIN)  reliability  for  large  data  transfers  to  remote 
sites.  Ihe  HiHCCS  Information  System  (BIS)  modernization 
program  addresses  the  BIN  deficiency  issues  of  power 
supplies  and  multi* level  security  and  proposes  changes  in 
the  BBMCCS  network  tc  allow  greater  interconnectivity  aaong 
sites. 

This  thesis  attempts  to  assess  the  BIS  modernization 
impact  cn  large  software  systems  in  the  WBMCCS  community,  in 
particular,  the  Joint  Deployaent  System  (JDS)  .  Specific 
deficiencies  in  areas  of  hardware  and  software,  surviv¬ 
ability,  and  management  will  be  addressed  and  planned 
improvements  analyzed.  The  modernization  program  should 
improve  computer  interconnectivity  aaong  the  joint  deploy¬ 
aent  community  in  the  future,  but  the  command-unique 
software  and  WBMCCS  standard  software  modifications  will 
provide  the  operational  reliability  necessary  for  operations 
in  the  interim.  With  the  conglomeration  of  subnetworks  into 
the  Defense  Data  Network  during  the  1983-1986  time-frame, 
plus  the  future  BIS  support  of  these  command-unique  software 
applications  and  the  improved  WBMCCS  Network,  the  joint 
deployment  ccaaunity  may  experience  a  more  reliable  system 
for  computer  resource  sharing. 
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E.  BI1IT1BT  C3  8BTVQBK 

The  Worldwide  Military  Command  and  Control  Systee 
(B9MCCS)  c£  the  Onited  States  centers  around  the  needs  of 
the  National  Coeaand  Authority  (NCA) .  A  Coeeand,  Control 
and  Ccaaunications  (C3)  process  can  be  considered  ar.  uncer- 
tanity  reducing  techrigue  which  aids  the  coaaander  in  the 
control  of  forces.  A  good  C3  systea  aust  per  ait  the  secure 
and  tiaely  flow  of  isfcraation  to  points  both  inside  and 
outside  the  Department  of  Defense  (DOD) .  This  flow  aust 
exist  during  all  scenarios  —  day-to-day  activities,  crises, 
conventional  conflict,  and  nuclear  war.  The  C3  systea  is  a 
aajor  ingredient  to  the  U.S.  national  goal  of  deterrence  of 
war.  [Bef.  1:  p.  53] 

Using  BWMCCS,  the  MCA  coaaunicates  its  desires  for 
deployaent  of  ailitary  forces  to  the  Joint  Chisfs  of  Staff 
(JCS).  In  short,  the  JCS  aission  can  be  defined  as  the 
execution  of  national  decisions.  This  aission  is  supported 
by  various  coaa unications  networks  and  command  and  control 
systeis,  cne  of  the  test  central  being  the  Joint  Deployaent 
Systea  (JCS)  which  provides  a  bridge  between  the  deliberate 
planning  process  and  tiae- sensitive  planning  and  execution. 
Connectivity  for  these  systems  is  provided  by  the  National 
Military  Coaaand  Systea  (NMCS)  which  consists  of  three 
command  centers:  the  National  ailitary  Command  Center 
(NHCC) ,  the  Alternate  National  ailitary  Coaaand  center 
(ANHCC) ,  and  the  National  Emergency  Airborne  coaaand  Post 
(NEACP)  .  Also  included  in  the  NMCS  are  the  various 
personnel  and  equipment  necessary  for  adequate  control  c? 
forces.  Clef.  2:  p.  36] 

The  Defense  Coaiunicaticns  System  (DCS)  is  the  founda¬ 
tion  for  worldwide  ccaaunications  during  both  peacetime  and 
crisis  situations.  The  DCS  covers  the  United  States, 

Europe,  and  the  Pacific  area  with  networks  such  as  the 


9 


Automated  Voice  Network  (AUTOVON)  ,  the  Automated  Secure 
Voice  Hetwork(AUTOSEVCCOB) ,  and  the  Autoeated  Digital 
Network  (AOTODIN).  NNHCCS  was  established  in  1962  and 
supports  the  coaaand  functions  of  the  NCA  by  supplying 
inforeation  through  an  online  data  base  systea.  Although 
coeaunicaticns  is  a  fundaaental  aspect  of  a  C3  systea, 
siaply  hawing  good  coaaunications  does  not  equate  to  an 
adequate  coxaand,  control,  and  coaaunications  systea.  The 
proper  balance  of  coaaand  and  control  and  coaaunications,  i' 
union  with  forces,  results  in  naxiaun  force  effectiveness. 
[Ref.  3:  p.  40] 

C.  BRHCCS 

HtiNCCS  evolved  in  the  early  1960's  from  a  loosely  knit 
conglcaeraticn  of  about  158  computer  systems,  using  30 
different  software  systems,  and  operating  at  81  locations; 
all  serving  the  JCS,  Unified  and  Specified  commands,  and  the 
Service  commands.  The  majority  of  these  systems  were  devel¬ 
oped  independently,  consequently  the  lack  of 
interoperability  within  the  total  system  proved  detrimental 
to  its  meeting  the  NCA  requirements  for  intercommunications 
among  sites.  As  the  concepts  of  C3  grew,  additional 
requirements  were  demanded  of  the  system;  these  requirements 
were  aet  sporadically,  and  by  1970,  there  was  an  evident 
need  for  a  SHNCCS  modernize ticn  effort.  In  June  of  1970, 
the  BUNCOS  Automated  Data  Processing  (AD?)  Program  was 
initiated  tc  improve  WWNCCS  support.  The  program's  goals 
included: 

(1)  reduction  of  cost  through  standardized  hardware 
and  software 

(2)  development  of  a  viable  Data  Base  Nanageaent 
Systea  (DBMS)  for  data  retrieval 

(3)  standardization  of  data  formats 


(4)  centralization  of  management  activities  (Sef.  4 

p.  2] 

Prior  to  this  effort,  the  WiHCCS  program  had  no  central 
authority  fcr  its  budgeting  or  management.  Numerous  organ! 
rations  were  responsible  for  the  various  aspects  of  the 
program;  fcr  instance,  the  WWHCCS  Council  provided  policy 
guidance  for  developaent  and  operation  of  the  system;  th* 
DCS  evaluated  WWHCCS'  overall  effectiveness;  various 
Assistant  Secretaries  of  Defense  provided  advice  on  system 
design  and  developaent,  warning  and  intelligence  matters, 
and  ADP  procurements ;  and  each  service  was  responsible  for 
funding  its  equipment  acquisition  and  software  development. 
The  WWHCCS  System  Engineering  Office  (WSEO)  ,  a  separate 
organization  in  the  Defense  Communications  Agency  (DCA)  ,  wa 
organized  in  the  mid  1970’s  to  coordinate  the  general  syste 
engineering  of  WWHCCS.  One  of  the  biggest  disadvantages  to 
the  WHHCCS  management  structure  was  that  the  Director,  CCA, 
also  Director,  wwhccs  Engineering,  reported  to  two  organize 
tions;  the  Assistant  Secretary  of  Defense  (C3H  fcr 
organization  and  technical  matters  and  the  chairman  cf  the 
JCS  fcr  doctrine,  operational  policies,  and  validation  cf 
requirements.  This,  compounded  with  the  fact  that  the 
Director,  DCA,  had  nc  authority  for  the  budgeting  or  manage 
ment  of  the  WHHCCS  program,  precluded  the  successful 
coordination  of  WWMCCS  ADP  developaent  efforts.  [Bef.  5:  p 
8] 

The  WHHCCS  ADP  Program  also  outlined  a  set  of  well- 
defined  requirements  which  included  the  capability  to 
process  large  amounts  of  data  within  a  reasonable  time, 
reliability  greater  than  99X,  user  and  maintenance  friendli 
ness,  and  small  physical  space  and  personnel  requirements. 
[Hef.  6:  p.  22] 
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lie  fitiHCCS  functions  which  support  related  missions  are 
grouped  tc  allow  each  family  of  functions  to  be  indepen¬ 
dently  defined  and  iaplemented.  Interfaces  among  the 
functional  families  are  well  defined.  One  of  the  basics  of 
the  11HCCS  architecture  is  the  concept  of  four  distinct 
functional  families  which  support  the  NCA,  JCS,  ar.d  Unified 
and  Specified  Commands.  They  are: 

(1)  Resource  and  Unit  Monitoring  ( ROM) 

(2)  Conventional  Planning  and  Execution  (CPE) 

(3)  Nuclear  Planning  and  Execution  (NPE) 

(4)  Tactical  Bar  ning/At  tack  Assessment  ana  Space 
Defense  (TW/1A  and  SD)  [  Bef .  7:  p.  1-1] 

In  addition,  WWSCCS  ADP  is  divided  into  three  catego¬ 
ries.  Category  A  includes  the  WWMCCS  standard  software,  tne 
backbone  of  WHHCCS  ACP  which  principally  supports  the 
coaaand  and  control  requirements.  Category  B  is  that  soft¬ 
ware  which  is  unique  to  a  particular  activity.  And  Category 
C  encompasses  the  newly  emerging  systems.  [Bef.  8:  p.  2] 

As  whmccs  grew,  utilization  of  the  waticcs  intercomputer 
Network  (WIN)  increased.  The  network  was  initiated  as  a 
prototype  at  three  sites  and  from  1977  to  1983  the  number  of 
SIN  sites  jumped  fro*  six  to  twenty- three,  with  future  plans 
eventually  including  all  WMMCCS  sites.  Commonly  used  func¬ 
tions  include: 

(1)  maintenance  of  status  and  location  of  forces  and 
resources 

(2)  planning  for  force  mobilization  and  deployments 

(3)  preparation  of  the  Single  Integrated  Operations 
Elan  (SIOP) 

(4)  estimating  and  monitoring  Navy  fleet  fuel 
consumption 

(5)  assisting  in  preparation  and  processing  cf 
AUTODIN  messages  [Bef.  9:  p.  5] 
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The  utilization  c £  the  Joint  Deployment  System  (JDS) 
contributed  to  the  increased  activi  /  on  the  BBMCCS  network. 
As  a  pzieary  function,  the  JDS  maintains  Tite-Phasod  Force 
Deployment  Data  (TPFDD)  files  for  specific  Operation  Plans 
(OPLABs)  outlining  the  supported  commander's  concept  of 
cperaticns  and  requirements.  [ Ref .  10:  p.  11]  Prior  to 
additional  software  development,  these  files  were  sent  to 
BIN  subscribers  in  their  entirety  to  initiate  JCS  exercises. 
As  the  TPFDD  files  were  updated  throughout  the  exercise,  the 
entire  file  was  again  sent  to  all  users.  These  large  data 
transfers,  coupled  with  an  overall  increase  in  BIN  usage, 
placed  a  burden  cn  network  components  and  host  processors, 
causing  BIN  performance  to  reach  an  unsatisfactory  level. 
Particular  site- unique  development  included  the  JDS  Remote 
User's  Package  (RUP)  ,  discussed  in  Chapter  3. 

A  new  surfacing  problem  was  the  lack  of  a  Multi-Level 
Security  (MLS)  systas.  A  MLS  system  allows  users  with 
varying  security  clearances  to  simultaneously  share  ccaputar 
equipment  with  access  to  various  software  allowed  on  a 
case-by-case  security  check.  One  theory  for  implementing  a 
MLS  system  is  the  usage  of  rings  of  protective  organization 
for  the  hardware.  Here,  the  operating  system  is  segmented 
into  N-rings,  with  M  greater  than  two.  The  inner-most  ring 
will  be  occupied  by  the  cere,  or  kernel,  of  the  operating 
system.  The  system  software  and  security  processes  will  be 
run  here;  for  instance,  validation  of  passwords  and  data 
access  requests.  The  resource  allocation  software  should 
reside  in  a  seperate  ring  for  scheduling  of  tasks  and 
computer  resources.  The  outer  rings  are  available  to  the 
users  for  processing  application  programs.  Routines  in  Ring 
'i»  have  access  to  Rings  'i*  and  all  rings  greater  but  can 
only  access  more  inner  rings  through  procedure  calls,  thus 
affording  the  proper  security  check  opportunity.  The  rings 
c£  prctecticn  secure  sensitive  software  and  data  and  also 
act  as  firewalls  against  user  damage.  [Bef.  11:  p.  540] 
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It  is  interesting  to  note  that  in  the  aid-1960*s  the 
Bassachuset * s  Institute  of  Technology,  Sell  Telephone 
laboratories,  and  the  coepater  department  of  the  General 
Electric  (G£)  Coapany  developed  one  of  the  first  operating 
systets  tc  eaploy  rings  of  protection,  the  Huitiplexed 
Inforaation  and  Computing  Systea  (MOLTICS) .  The  original 
BOLTICS  was  installed  on  a  GE645,  later  a  Honeywell 
Information  Systea  (HIS)  64  5  coaputer,  and  in  1973,  replaced 
by  the  HIS  6180.  The  HIS  6180  supports  eight  rings  of 
protection:  the  operating  systea  uses  Rings  0-3;  Rings  4-7 
are  available  to  the  users,  [Ref.  11:  p.  5351  With  r.o  HLS 
systea,  all  aachines,  terainals,  and  personnel  on  the  Bin 
must  be  cleared  to  the  highest  level  being  utilized. 

[Ref.  12:  p.  7] 

ether  probleas  included  the  lack  of  a  leng-range  plan 
for  BBHCCS/BIS  develcpaent  and  the  early  1960  Honeywell 
architecture  which  is  not  the  state-of-the-art  for  at  online 
query  and  response  systea. 

l  aiscoEception  was  also  prevalent  concerning  WW.HCCS  — 
that  it  would  provide  coaaunicat ions  between  the  President 
and  the  fcxhcle.  This  was  never  the  design  intention  of 
HWMCCS;  however,  what  was  desired  was  a  conmunications 
network  fer  several  ccaaand  echelons  and  a  reliable  ailitary 
coaaand  and  control  systea  connecting  the  NCA  to  the 
executing  ccaaanders.  [Ref.  1:  p.  40] 

Although  the  reliability  of  the  SRMCCS  Intercomputer 
Hetwork  (BIS)  had  fallen  below  a  satisfactory  level,  tae 
HBRCCS  AEE  sites  utilized  the  on-site  Honeywell  coaputer 
equipment  tc  develop  software  applications  for  unique 
requirements.  By  the  aid  1970*s,  there  was  a  great  depen¬ 
dency  on  BBMCCS  ADP  for  day-to-day  operations  and 
crisis/exercise  support  and  the  need  for  a  reliable  ccaputer 
network  became  obvious.  (Ref.  12:  p.  7] 
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ii.  sm££5  uiaiimai  sxsm i 


1.  B1CKGBOOBD 

Is  Hcvember  1981,  the  Deputy  Secretary  of  Defense 
decided  the  HHHCCS  Infor nation  System  (HIS)  nodernizaticn 
Flan  needed  a  focal  Feint  for  coordination  to  receive  policy 
and  guidance  directives  fron  the  JCS .  In  January  1982,  a 
US  Joint  Program  Hanager  (JPM)  vas  appointed  to  control  the 
joint  modernization  activities  of  HWMCCS  ADP  and  the  devel¬ 
opment  of  all  telecommunications  interfaces.  Small 
site-unique  enhancements  will  continue  to  be  processed 
normally.  The  HIS  JEH  receives  direction  from  the  JCS  and 
reports  through  the  JCS  to  the  secretary  of  Defense. 

[Ref.  8:  p.  04] 

A  System  Progam  Cffice  (SPO)  was  established  within  the 
Air  Force  Electronic  Systems  Division  to  manage  wis  acquisi¬ 
tion  and  provide  support  in  such  areas  as  architecture  and 
system  engineering.  The  SPO  also  maintains  Air  Force 
programming  and  budgeting  data  for  the  HIS  modernization 
plan.  [Bef.  8;  p.  44]  The  Director,  DC  A  and  the  His  JPM 
have  signed  a  Metorardum  of  Agreement  which  specifies  the 
guidelines  for  the  Command  and  Control  Technical  Center 
(CCTC)  support  tc  the  HIS  modernization  effort. 

The  basic  goal  for  the  HIS  modernization  program  is  tc 
provide  the  BCA,  JCS,  and  Unified  and  Specified  commanders 
with  real  time  access  to  status  and  warning  information. 

HIS  objectives  inclade:  improved  HHHCCS  performance, 
greater  HIM  reliability,  modernization  of  HHMCCS  ADP  harware 
and  software,  and  increased  ADP  security.  Of  the  three 
HHHCCS  ADP  categories  mentioned  previously,  HIS  will 
centralize  its  effort  on  Category  A  —  HHHCCS  standard 
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software,  cf  the  four  functional  faailies  of  operational 
requirements,  HIS  will  focus  only  on  two:  Resource  and  onit 
Honitcring  (BOB)  and  Conventional  Planning  and  Execution 
(CPS).  The  Air  Force  will  continue  to  nanage  the  HWBCCS  ADP 
systems  in  the  Nuclear  Planning  and  Execution  (NPS)  and 
Tactical  Narning/Att ack  Assessment  an.i  Space  Defense  (TH/AA 
and  SC)  areas.  (Ref.  8:  p.  18] 

C.  SYSTZB  DESIGN 

The  NNBCCS  Inforaation  System  (HIS)  was  designed  as  an 
interactive  network  system  in  which  a  user  at  any  command  or 
agency  can  ccnaunicate  with  a  user/host  at  any  other  command 
cr  agency  also  connected  to  the  network.  The  Defense  Data 
Network  (CDN)  will  provide  the  interconnection  among  HWHCCS 
sites.  A  Network  Operations  Center  will  monitor  the  network 
as  a  separate  node  on  the  DEN.  Local  area  networks  (LANs) 
will  exist  for  secure  and  interactive  communications.  The 
advantages  to  LANs  include:  usual  ease  in  configuring 
systems  to  meet  specific  site  requirements,  development  of 
standard  components  fcr  common  functions,  flexibility  for 
selective  modernization,  and  the  ability  to  develop  incre¬ 
mental  security  solutions.  Figure  2.1  graphically  depicts 
the  user  support  scheme  envisioned  by  HIS. 

(Ref.  8:  p.  3] 

The  HIS  system  objectives  include: 

(1)  user-friendly  interface  development 

(2)  data  processing  capabilities  fcr  all  HHHCCS 
sites 

(3)  reliable  inter-command  communications 

(4)  improved  processing  capabilities  during  battle 
conditions  ( Bef .  8:  p.  IS] 
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COMPONENTS 


INTERNOOAL 

NETWORK 


•  OUTGOING  MESSAGES! 
«  QUERY/RESPONSE  ■ 

•  TELECONFERENCE  1 

•  01 SPLAYS  ’ 

•  OATA  BASE  SUMMARIES 


C  AGENCIES  jS> 

JRS  MESSAGES  ^ 
•  OTHER  MESSAGCS 
•  OUERT/RESPONSE 
>  •  TELECONFERENCE 
•  DISPLAYS 
•  OATA  BASE  UPOATES 


GATEWAY  •  FILE  TRANSFERS 


EXTERNAL  INTERFACES 


•  AOP  SERVICES 

•  OATA  COMMUNICATIONS 
«  VIOEO  SERVICES 

•  WORK  STATION  SERVICES 

•  CRYPTO 


•  COMMANO  CENTER  PERSONNEL 

•  CRISIS  ACTION  TEAMS 

t  OPERATIONS'  SUPPORT  PERSONNEL 
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Projected  VIS  characteristics  to  accomplish  these  goals 
are  divided  into  three  categories:  access*  availability*  and 
modularity. 

Access  characteristics: 

(1)  organic  Mis  support  for  aajor  sites 

(2)  reaote  access  capability  for  snail  sites 

(3)  user  access  fron  a  single  work  station 

(4)  a  nulti-level  security  systes 

(5)  niniaun  site  training  reguireaent 
Availability  characteristics: 

(1)  secure  and  interactive  network 

(2)  operational  for  day-to-day  and  crisis  support 
Hodularity  and  flexifcilty  characteristics: 

(1)  accomodation  of  a  wide  range  of  sites 

(2)  standard  software 

(3)  niniaun  iaplementation  disruption 

(4)  state-of-the-art  technologies  considered 

[Hef.  8:  p.  16) 

C-  SISTEB  STBOCTUBB  GOIDBLIHES 

The  BIS  JPH  Cffice  has  developed  guidelines  for  BIS 
systea  requirements  in  the  areas  of  standardization, 
security,  and  system  characteristics. 

Hardware  standardization  will  not  be  mandatory  because 
of  the  nuaerous  existing  systems  and  the  competitive 
procurement  possibilities.  Software  development  standardi¬ 
zation  will  be  achieved  through  the  exclusive  use  of  ADA  as 
the  pzcgran  design  language.  Standard,  pre-daternined 
protocols  will  set  the  intercomputer  communications  stan¬ 
dards.  Bcutine  and  emergency  maintenance  will  be  monitored 
by  a  single  organization;  maintenance  standards  will  be 
imposed.  To  facilitate  cooperation  among  the  remote  sites, 
data  definition  standards  will  be  implemented.  [Bef.  8:  p. 
31] 
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The  core  of  the  SIS  security  program  lies  in  the  multi¬ 
level  secure  LANs  with  secure  interfaces  to  all  other  sis 
components.  Authentication  for  users  will  be  applied  as  a 
security  control  with  an  audit  capability  available.  DCD 
security  requirements  require  that  a  multi-level  security 
systea  be  achieved  within  the  SIS  modernization  program. 
[Bef  •  8:  p.  3h  ] 

the  SIS  modernization  program  will  provide  capabilities 
to  improve  communication  survivability  and  ADP  support  to 
HSHCCS  sites.  Seme  proposed  capabilities  are: 

(1)  distributed  and/or  redundant  processing  with 
remote  access 

(2)  graceful  degradation 

(3)  rapid  restart  and  recovery 
(«)  distributed  data  files 

(5)  transportable  systems 

Standards  for  accessibility  include  the  ability  to 
access  all  MIS-related  capabilities  from  a  single  worksta¬ 
tion.  Other  required  systea  capabilities  are  flexibility, 
reliability,  maintainability,  and  interoperability. 

[Bef.  8:  p.  35] 

0.  I  IP  t  EBB  WAT  I  Oil 

MIS  will  be  implemented  during  four  modernization 
segments  and  utilizirg  four  major  contracts.  The 
Haiatenance  Segment  includes  the  near-term  enhancements  to 
the  baseline  hardware  and  software  to  stabilize  MIS  perfor¬ 
mance  and  will  be  accomplished  through  the  Integration 
Contract.  Best,  the  Transition  Segment,  linked  to  the 
Common  User  contract,  transfers  the  user  communities  from 
the  existing  MMBCCS  ADP  to  the  MIS  modular  architecture  fer 
future  modernization  and  initiates  the  Automated  Hessage 
Handling  capabilty.  The  Joint  aissicn  Segment  concentrates 


19 


on  the  coaacn  applications  software  modernization;  the  Joint 
Mission  Hardware  contract  will  provide  the  standard  hardware 
base  and  supporting  operating  systea  by  late  FY85.  The 
final  segaent  will  be  the  Service  and  Coaaand  unique  appli¬ 
cation  software  iaproveaents  which  will  be  the 
responsibility  of  the  Services  and  user  coaaands.  Figure 
2.2  illustrates  the  BIS  growth  through  the  four  moderniza- 
tion  segaents.  [Bef.  8:  p.  3]  The  last  major  contract,  the 
Configuration  Hanageaent  contract,  provides  for  independent 
validation  of  the  software  provided  by  the  Integration  and 
Common  User  contractors.  In  addition,  this  contractor  will 
assist  the  HIS  JPH  in  the  overall  configuration  management 
of  BIS.  [Bef.  13:  p.  9] 

1.  E1ALUATICH/C0HPABIS0  N  BFFOBT 

As  mentioned  earlier,  one  of  the  major  problems  in  the 
HHHCCS  community  is  the  unsatisfactory  performance  of  the 
HiflCCS  Intercomputer  Network  (HI'S).  In  September  1981, 
Director,  DCA  organized  an  effort  to  investigate  the 
replacement  of  the  present  BHHCCS  network  system  with  a  more 
contemporary  system. 

Initially,  the  idea  surfaced  to  take  advantage  of  the 
proven  AOTCEIN  I  technology  and  develop  an  AUTODIN  II.  It 
was  envisioned  that  AUTODIN  II  would  provide  a  common  user 
data  network  with  a  irulti-level  security  systea  to  meet 
network  requirements  through  1985.  In  1976,  the  contract 
was  awarded  to  Western  Union,  Inc.  and  the  Initial 
Operational  Capability  (IOC)  was  set  for  January  1979. 

[Baf.  14:  p.  44] 
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Maintenance  Segment  Transition  Segment 

(Integration  Contract)  (Common  User  Contract) 


Systems  Modernization  I  site  Unique  Software  Improvements 


Beginning  in  1979,  the  IOC  date  was  extended  several 
times  until  July  1980,  when  the  Assistant  Secretary  cf 
Defense  fcr  Command,  Control,  Coaaunications  and 
Intelligence  (ASBC3I)  requested  a  review  of  the  AUTODIN  II 
project  with  sose  possible  alternative  proposals.  In  July 
1981,  the  Deputy  Under  Secretary  of  Defense  for  C3I 
(DOSDC3I)  questioned  the  wartiae  survivability  of  AOTODIN 
II.  Ihe  doubt  focused  on  one  of  the  basic  design  criteria 
for  the  systea  --  a  saall  nuaber  of  switching  nodes.  These 
switching  nodes  would  require  aanning  and  would  be  rela¬ 
tively  expensive.  Iamediately  after  this,  the  Air  Perce 
Test  Director  issued  a  report  concerning  the  increasing  cost 
of  the  systea  and  doubts  about  the  technology  and  future 
systet  perfcraance.  [Ref.  14:  p.  45] 

In  late  1981  the  Director,  Defense  Coaaunications  Agency 
(DC A)  established  three  design  teams: 

Team  1  -  -  tasked  with  designing  the  best  possible, 
survivable  AUTODIN  II  3  y stem 

Teas  2  --  tasked  with  designing  the  best  alternative 
which  would  be  based  on  the  ARPANET  and  WIN  tech¬ 
nology,  a  Replica  approach 
lean  3  --  a  30-day  evaluation  team. 

The  evaluation  team  was  to  establish  guidance  fcr  the 
two  design  teams  and  develop  evaluation  criteria.  [Ref.  14: 
p.  45]  Seme  of  the  evaluation  factors  considered  were 
survivability,  security,  systea  design,  and  ccst.  The 
ARPANET  replica  proposal,  referred  to  as  the  Replica,  seemed 
better  able  to  withstand  network  element  losses,  proposed  a 
more  flexible  routing  algorithm,  and  afforded  a  greater 
mobility  capability.  [Ref.  15] 

AOTQCIN  II  now  had  a  six-year  old  design  and,  because  of 
continuous  technology  advances,  the  expected  life  cf  a 
computer  system  is  about  eight  years.  In  the  area  cf  large 
data  transfers,  AUTOCIN  II  was  superior  to  the  Replica 
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design.  The  Beplica  design  would  be  asing  sealler  packets 
for  message  transfers  throughout  the  network  —  smaller 
packets  necessitate  more  nuaerous  packets  which  in  turn 
increase  the  overhead  traffic  through  the  system  and  car. 
degrade  system  performance.  If  AUTO  DIN  II  had  been  aval* 
lable  fcr  iipleeentation  during  the  evaluation  effort  time 
frame,  the  technology,  schedule,  and  cost  risks  associated 
with  the  Beplica  proposal  would  certainly  have  cancelled 
some  of  the  benefits.  However,  having  no  satisfactory 
10TODIH  II  system  online,  the  benefits  of  the  Hsplica 
approach  justified  the  risks.  [  Bef .  15] 

In  constant  FY82  dollars,  AUTODIN  II  total  systea  cost 
was  estiaated  at  S586  million  where  the  Beplica  total  system 
cost  was  $429  million.  It  was  projected  that  the  AUTODIN  II 
annual  operating  costs  would  steadily  increase  to  $72 
million  until  1995,  where  the  annual  cost  would  level  off 
near  $55  aillion.  The  Beplica  systea  annual  cost  is 
expected  to  peak  at  $71  aillion  around  1985  and  steadily 
decrease  to  the  $40  aillion  range  in  1987.  Figure  2.3  shews 
DDN/Beplica  annual  ccsts.  [Bef.  15] 

In  February  1982,  the  evaluation  was  completed.  Based 
cn  the  conclusions  the  Director  of  DCA  decided  the  Replica 
approach  would  provide  a  better  DOD  data  network. 
Conseguently,  the  Deputy  Onder  Secretary  cf  Defense  ordered 
the  termination  of  the  AUTO  DIN  II  network  and  the  initiali¬ 
zation  of  the  Beplica  design,  to  be  known  as  the  Defense 
Data  Network  (DDN) .  [Bef.  14:  p.  45] 

I.  DIIB1SE  DATA  NETBOBK 

The  Defense  Data  Network  (DDN)  will  provide  the  Wis 
community  with  the  secure,  reliable,  interactive  network 
necessary  tc  perform  its  functions.  The  DDN  is  designed  as 
a  single,  integrated  packet -switching  data  network.  The 
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Figure  2.3  DDM/Heplica  Annual  Costs. 

completed  network  will  have  91  subscriber  systems  with 
approximately  488  hosts  and  1,446  terminals.  There  will  be 
171  switching  nodes  at  85  sites.  The  DDN  meets  the 
Sorldwide  Digital  System  Architecture  (WWDSA)  standards  and 
objectives  by  providing  a  solid  technology  base,  low  risk, 
and  a  cost  effective  system.  This  network  will  satisfy 
current  survivability  requirements  during  a  crisis  and  meet 
COD  intercomputer  telecommunication  requirements  supplied  by 
the  JCS.  [Bef.  16:  p.  2] 

The  major  DDK  design  concepts  are  standardized  compo¬ 
nents,  distributed  switching  nodes,  and  automatic  fault 
recognition.  Standardized  components  allow  smaller  develop¬ 
ment  costs  and  lower  maintenance  and  support  costs.  Also, 
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component  modularity  reduces  the  maintenance  impact. 
Distributed  snitching  nodas  aid  in  eliminating  choke  points 
which  increases  the  overall  survivability  of  the  system.  A 
wide  distribution  of  switching  nodes  usually  minimizes  any 
iepact  after  a  single  node  failure.  Another  major  concept, 
the  DCN  automatic  fault  recognition  system,  is  implemented 
through  a  series  of  Monitoring  Centers  (MCs)  which  are  in 
continuous  operation  to  monitor  network  performance  and 
identify  trouble  areas. 

The  network  Monitoring  Centers  will  be  key  nodes  cr  the 
DDN  network.  There  will  be  a  principal  system  MC,  an  alter¬ 
nate  HC,  regional  MCs  for  Europe  and  the  Pacific  area,  and  a 
HC  for  each  keyed  community.  Primary  functions  for  the 
monitoring  centers  will  include: 

(1)  monitoring  the  status  of  the  network 

(2)  isolating  network  faults 

(3)  supporting  software  maintenance 

(4)  providing  network  element  information  [Ref-  16: 
p.  5] 

The  Defense  Data  Network  will  provide  four  levels  ci 
support  tc  the  current  SHMCCS  community: 

level  1  —  best  processor  sites  fer  Resource  and 
Or.it  Monitoring  (BOM)  and  Conventional  Planning  and 
Execution  (CEE)  support 

Level  2  —  limited  on-site  processor  support  plus 
access  to  remote  host  processors 

level  3  —  processor  support  through  network  access 
tc  remote  processors  in  Hawaii 

Level  4  —  support  through  individual  terminals 
connected  to  remote  host  data  processors  [Bef.  8:  p. 
27] 

The  Defense  Data  Network  is  designed  fer  continuous 
operation  tc  support  real  time  handling  of  all  user's 
traffic.  The  availability  goal  is  greater  than  993  for  any 
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pair  cf  users.  [Bef.  17:  p.  5]  The  three  major  DDK  system 
elements  are  switching  nodes,  IPLIs,  and  Mini-TACs. 

The  switching  node  used  for  the  DON  is  a  Eoit  3eraneic 
and  Newman  (BBN)  C/30  switch,  a  microprogrammed  minicomputer 
designed  for  unattended  operations  which  eliminates  the  need 
for  DEN  dedicated  personnel  at  each  switching  node.  The 
throughput  capability  of  each  C/30  node  is  300  packets  per 
second  in  tandem  processing  —  300  packets  in,  300  packets 
switched,  and  300  packets  out  simultaneously,  for  a  total  of 
900  packets  being  handled.  The  long  term  reliaoility  goal 
is  5000  hours  or  greater  for  Mean  Time  Between  Failures 
(MTBF).  The  development  risks  are  low  since  the  C/30  switch 
and  its  software  are  functioning  elements  on  such  networks 
as  the  ARPANET;  SIN;  Community  On-Line  Intelligence  Network 
(COINS)  ;  Intelligence  Data  Handling  System,  Communications 
(IDHSC)  ;  and  the  European  Movement  Information  N-twcr> 

(MINE!)  .  Technology  risks  are  considered  low  since  c:ly 
minor  modifications  are  neccessary.  [Ref.  1&s  p.  33] 

The  Internet  Private  Line  Interface  (IPLI)  is  based  on 
the  Private  Line  Interface  (PLI)  which  has  been  used  or.  the 
ARPANET  and  other  networks  for  acre  than  five  years.  The 
PLI/IFLI  technology  allows  the  simplest  of  end-to-end 
encryption  available.  An  ILPI  will  reside  between  a  host 
and  switching  node  or  Mini-Terminal  Access  Controller 
(mini-TAC)  and  switching  node,  depending  on  site  configura¬ 
tion.  The  IPLI  is  currently  under  development  with  an 
initial  delivery  date  of  July  1983.  It  will  support  the 
standard  COD  protocol,  Internet  Protocol  (IP),  and  widesp¬ 
read  deployment  is  eipected  because  of  reduced  cost,  site, 
and  pcwer  and  weight  requirements  from  the  PLI  currently 
being  used.  The  IPLI  hardware  consists  of  a  KG-84  crypto¬ 
graphic  device  and  two  Motorola  MC68000- based  packet 
processors.  A  minimum  of  fifty  packets  per  second  is  set  as 
a  throughput  goal  and  the  MTBF  goal  is  at  least  5000  hours. 
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The  Mean  Time  To  Repair  (MTTR)  is  expected  to  be  approxi¬ 
mately  thirty  minutes  with  an  availability  of  99. 9*.  The 
IPLI  requires  no  additional  personnel  and  the  maintenance 
and  acnitcring  systems  may  be  operated  from  a  remote  site. 
The  development  risk  involved  is  considered  low  due  to  the 
traditional  architecture  used.  [Ref.  14:  p.  39] 

i  Mini-Terminal  Access  Controller  (sini-TAC)  is  a 
terminal  access  device  which  allows  a  cluster  of  up  to 
sixteen  terminals  simultaneous  access  to  the  network.  The 
hardwara  of  a  mini -T AC  is  a  MC68000  microprocessor  with 
memory  and  multiple  network  interface  ports.  The  mini-TAC 
software  is  based  on  the  software  developed  for  use  on  the 
ARPANET  and  allows  terminal  users  to  establish  connections 
between  their  terminals  and  an  arbitrary  host  on  the 
network.  The  DOD  standard  IP  and  Transmission  Control 
Frotccol  (TCP)  are  used.  The  MTBF  gcai  is  greater  than  5000 
hours  and  the  bo ard-swappin g  capability  simplifies  mainte¬ 
nance.  '  Since  the  miri-TAC  is  also  designed  fer  unattended 
operations,  no  dedicated  personnel  are  required,  control 
acnitcring  and  hardware/software  fault  isolation  c an  be 
accomplished  remotely  by  the  MCs.  Mini-TAC  availability  is 
expected  during  FY84.  [Ref.  16:  p.  42] 

One  cf  the  major  comparison  factors  for  the  AUTOCIN 
II/DDN  evaluation  was  survivability.  Tne  small  number  cf 
nodes  preposed  fer  the  AUTODIN  II  system  left  major  doubt  as 
to  its  survivability.  DDN's  survivability  features  include: 

(1)  redundancy  --  the  final  system  will  comprise  171 
switching  nodes,  9  fixed  monitoring  centers,  and  5 
mobile  reconstitution  nodes  witn  MC  capability 

(2)  disseminated  switching  nodes  --  geographically 
dispersed  sites  afford  the  higher  priority  users  a 
greater  chance  of  reconstitution 

(3)  a  dynamically  adaptive  routing  algorithm  which 
automatically  reroutes  traffic  around  heavily  cong¬ 
ested  or  damaged  links  and  nodes 
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(4)  graceful  degradation  because  of  the  network’s 
response  to  damaged  nodes 

(5)  four  levels  of  precedence/preemption  processing 

(6)  hardening  and  HEMP  protection  including  electro¬ 
magnetic  shielding,  line  isolation,  and  power  surge 
protection 

(7)  reconstitution  —  the  five  mobile  reconstitution 
nodes  will  be  posit ioned  in  areas  less  likely  to  be 
targeted  and  all  users  will  have  a  detailed  alterna¬ 
tive  routing  plan 

(8)  preplanned  rehoair.g  —  all  users  will  have  a 
priority  listing  of  switching  nodes  fcr  rehomirg 

(Bef.  16:  p.  125] 

DEN  security  will  be  accomplished  through  link  encryp¬ 
tion,  end-tc-end  encryption,  and  physical  and  procedural 
security  measures.  The  KG-84  cryptographic  devices  will 
provide  the  necessary  link  encryption.  The  Internet  Private 
line  Interface  (IPLI)  devices  between  the  host  and  switching 
node  cr  aini-TAC  and  switching  node  will  provide  the 
end-tc-end  encryption.  The  IP LI  will  also  separate  subscri¬ 
bers  operating  at  different  system  security  levels.  For 
physical  security  measures,  all  switching  nodes  will  be 
TEMPEST  enclosed  and  located  ir.  secure  military  facilities. 
Only  System  Monitoring  Center  {SMC)  personnel  will  be  able 
to  retrieve  traffic  statistics.  All  personnel  at  regional 
and  system  KCs  and  personnel  with  access  to  switching  redes 
will  hold  a  SECRET  clearance.  In  addition,  personnel  with 
access  to  a  HC  for  a  secure  subnetwork  must  also  be  cleared 
to  the  highest  security  level  of  the  subnetwork  subscribers. 
[Bef.  16:  p.  12] 

The  EDM  program  office  is  within  the  DCA  organization 
and  consequently  comes  under  DCA's  staffing  and  policies. 

The  National  Security  Agency  (NS A)  has  the  responsibility 
for  certifying  and  accrediting  the  IPLI  devices  and 
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analyzing  the  network  system  design  for  use  with  classified 
traffic.  DON  subscribers  will  be  responsible  for  acquiring 
the  recessary  hardware  and  software  for  DON  operation  and 
suppcrt.  [Bef.  14:  p.  258] 

irctber  sajor  factor  considered  during  the  evaluation 
phase  was  cost.  According  to  the  evaluation  tea®,  the  "DDN 
I  systea  can  provide  COD  with  a  survivable,  common-user 
system  at  a  cost  less  than  being  paid  for  the  dedicated 
systems...".  (Bef.  16:  p.  15]  Using  FT82  dollars,  the  91 
dedicated  systems  listed  in  the  user  requireaent  data  bass 
cost  ever  $35.2  million  for  annual  operation.  The  annual 
cost  for  the  new  DDN  system  includes: 

Systea  Management  3,354  K  (10. 3%) 

Trunk/Access  Lines  24,694  K  (  7.6?) 

Operations  and  Management  4,428  K  (13.61) 

Tctal  $32,476  K  Annually 

When  development  and  acquisition  costs  are  included,  DDN 
annual  operating  costs  average  $35,549  million  over  a  ten 
year  period.  (Bef.  16:  p.  255] 

The  Defense  Data  Network  system  design  builds  on  three 
cperational  networks  which  use  the  BBN  C/30  switching  node 
and  accompanying  software: 

(1)  A2PANET  —  with  90  nodes  at  75  locations 

(2)  WIN  —  with  26  nodes  at  16  locations 

(3)  MINET  —  with  European  locations  [Bef.  17:  p.  2] 
The  DDN  will  employ  a  four  stage  implementation  approach 

which  should  lead  to  a  graceful  evolution  capitalizing  on 
existing  networks  and  interfaces  with  minimum  risk  fer  new 
technologies.  The  ARPANET  will  supplement  DDN* s  test  and 
development  facilities  but  will  remain  as  a  sealed-dewn 
research  network.  It  will  later  serve  as  an  operational 
testbed  for  future  DDN  software  releases.  [Bef.  16:  p.  24] 
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The  four  transition  stages  for  DDN  Z  are: 

Stage  1  —  service  will  be  provided  to  subscribers  that 
can  be  handled  with  ainiaue  development.  The  ffWMCCS  Network 
C/30  switch  upgrade  will  be  accomplished  during  this  stage. 
Communities  of  interest  and  networks  with  differing  security 
levels  will  be  physically  separated  into  three  distinct 
networks: 

(1)  Strategic  Air  Command  Digital  Network  (SACDIN) 

—  at  a  Top  Secret  (TS)  system-high  security  level 

(2)  Hilitary  Network  (NIL NET)  —  for  unclassified 

subscribers  tc  include  military  ARPANET  users 

(3)  Command  and  Control  Intelligence  (C2I)  Network 

—  with  a  TS  system-high  security  level  network  with 

twc  subnetwork  communities: 

the  C2  Comiunity  basically  for  WIN  subscribers  and 
the  Intelligence  Community  primarily  for  IDHS 
TI/Deoartment  of  Defense  Intelligence  Information 
Systems  (DCEIIS)  users. 

Stage  1  is  expected  tc  be  completed  by  end  of  PY83. 

Stage  2  --  As  additional  IPLIs  become  available  during 
1984  ,  more  subscribers  will  be  added  to  the  network.  The 
mini-TACs  will  be  implemented  in  Stage  2,  also.  Completion 
is  expected  by  the  end  of  FY84. 

Stage  3  —  During  Stage  3,  the  three  separate  networks 
originated  during  Stage  1  will  be  integrated  to  become  the 
DDi?  I,  supporting  multiple  levels  of  security.  During  this 
stage,  additional  classified  subscribers  will  be  incorpo¬ 
rated  into  the  network.  Stage  3  will  be  completed  by  the 
end  cf  FY85. 

Stage  4  —  As  host  interfaces  are  developed,  all 
remaining  DCN  subscribers  will  be  included  in  the  network. 
The  final  DDN  I  network  will  consist  of  171  nodes  supporting 
91  systems,  and  the  EEN  system  design  allows  for  a  moderate 
increase  in  traffic  from  each  network  user.  [Ref.  16:  p. 
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189]  figure  2.4  shoes  the  transition  plan  for  the  DON  I. 

(Bef.  16:  p.  190] 

G.  M1S/ECI  CONNICTICN 

currently,  the  Defense  Communications  Agency  provides 
HHMCCS  software  support  through  the  Command  and  Control 
Technical  Center  (CCTC) .  Although  the  MIS  modernization 
plan  is  net  a  part  of  DC  A,  the  MIS  JPM  and  the  Director  of 
CCA  have  entered  a  Memorandum  of  Agreement  which  insures 
CCTC  support  during  th9  Mis  modernization  effort.  However, 
since  plans  call  for  the  Defense  Data  Network  (DDN)  to  be 
integrated  into  the  ECS,  the  DDN  program  office  falls  under 
the  CCA  organization.  The  DDN  will  provide  a  common  user 
network,  capable  of  incorporating  the  majority  cf  the  C3 
networks  available  today  and  providing  a  standard,  secure 
and  shared-resource  capability. 

The  DCN  will  not  be  restricted  to  support  of  the  WHHCCS 
community.  As  can  be  seen  free  Figure  2.4,  networks  such  as 
the  SIC  Digital  Network  (SACDIN)  and  the  ARPANET  will 
utilize  the  Defense  Data  Network  for  intercommunications 
among  member  sites,  Mith  these  various  user  communities 
riding  cn  one  network  system,  a  multi-level  security  system 
is  imperative,  although  technology  hinders  the  development 
cf  such  a  system.  The  management  of  the  DDN  network,  a 
network  where  users  range  from  unclassified  military  users 
cn  the  ARPANET  tc  high  classification  users  of  the  JDS  on 
the  MIN,  has  not  been  sufficiently  addressed  and  will  become 
the  source  cf  major  problems. 

As  DCN  comes  into  being,  new  WMNCCS  standard  software 
will  be  implemented  under  the  MIS  modernization  plan  and 
existing  site- unique  software  will  be  modified  to  reflect 
the  updated  system.  These  software  changes  and  future  hard¬ 
ware  acquisitions  will  affect  every  system  used  within  the 
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1RBCCS  ccaaunity.  The  HIS  aodernizatior.  i  a  pact  will  be  felt 
by  all  users  supported  by  the  Joint  Deployaent  systea  (JDS), 
cne  of  the  eost  widely  used  WHBCCS  systeas  and  the  total 
■anageeent  systea  coordinating  the  links  between  deliberate 
planning,  tiae-aensitiee  planning,  and  deplcyaent  cf  forces. 
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III.  10IHT  OBPLOTHg»T  STSTEH 


1.  BACKGROUND 

In  October  1978,  the  JCS  conducted  a  command  post  exer¬ 
cise,  NIFTY  HOGGET,  tc  test  full  mobilization  and  deployment 
capabilities  for  O.S.  forces.  NIFTY  HOGGET  exposed  defi¬ 
ciencies  in  both  the  military  deployment  planning  and 
execution  process  as  well  as  the  supporting  Management 
Information  System  (MIS)  .  The  systems  most  widely  utilized 
during  NIFTY  HOGGET  included  the  Joint  Operational  Planning 
Systet  (JCPS) ,  Onit  Status  and  Identification  Report 
(ONITBEP)  System,  and  command  unique  systems  such  as  the 
Deployment  Management  System  (DEPMAS)  used  by  the  O.S. 
Readiness  Command  (OSREDCOM).  JOPS  supported  planning  tut 
supplied  no  support  for  the  execution  phase.  The  ON  IT  REP 
system  was  not  responsive  tc  time-sensitive  decisions. 

CEPHAS  was  not  available  to  the  joint  deployment  community, 
the  system  dealt  with  Army  and  Air  Force  forces  only.  The 
need  for  a  centralized  deployment  and  decision  support 
systex  fcr  planning  and  execution  was  evident.  In  March 
1979,  the  Joint  Deployment  Agency  (JDA)  was  established  tc 
support  the  JCS  and  supporting  commanders  as  the  nucleus  of 
deployment  and  associated  activities.  10;  p.  3] 

The  Joint  Deployment  System  (JDS)  ,  resident  at  the  Jcint 
Deployment  Agency,  was  created  to  support  the  JDA  mission. 
The  JCS  includes  personnel,  procedures,  directives,  communi¬ 
cations  systems,  and  electronic  data  processing  systems 
which  support  peacetime  planning  and  time  sensitive  planning 
and  procedures.  The  JDS  concept  is  the  development  cf  a 
single  support  system  for  all  stages  of  deployment  manage¬ 
ment  with  particular  focus  on  planning,  deployment 
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execution,  and  crisis  monitoring.  After  the  JCS  exercise 
crder  is  delivered,  the  JDS  allows  the  aonitoring  of  move¬ 
ment  of  forces,  aateriel,  and  non-unit  related  personnel. 

The  Master  Fcrce  List  (SFL)  file,  schedule  file,  scheduling 
raquireaents  and  ONIIBEP  data  are  generated  froa  the  deploy¬ 
ment  data  base  and  distributed  to  users.  [Bef.  10:  p.  18] 
Through  the  JDS,  the  Joint  Chiefs  can  achieve  direct  imple- 
eantaticn  of  their  deployment  decisions  during  peacetime, 
command  pest  exercises,  crises,  and  war.  [Bef.  18:  p.  1] 

E.  JES/B1I  LIIK 

The  mission  cf  the  JDA  obviously  depends  on  interconnec¬ 
tivity  among  the  joint  deployment  community.  The  WMMCCS 
Intercomputer  Network  (MIN)  is  used  to  organize  these 
geographically  separated  host  computers  intc  a  single 
network  ard  becomes  the  backbone  of  the  JDS  communications 
system,  essential  in  th9  planning  and  execution  of  deploy¬ 
ment  decisions.  The  deployment  data  case  depends  on  MIN  for 
accurate  information  exchange  between  user  sites  and  the 
JDA.  [  Ref .  19:  p.  1]  Figure  3.1  illustrates  the  MIN  rela¬ 
tionships  within  the  joint  deployment  community.  [Ref.  20: 

F.  12] 

Transaction  throughput  is  site  dependent  but  a  JCA  site 
will  usually  average  1200  transactions  per  hour.  User 
response  tine  is  dependent  cn  the  number  of  users  simultane¬ 
ously  accessing  MIN.  For  example,  with  an  average  of  ten 
simultaneous  users,  SIN  response  time  averages  two  to  five 
seconds.  Ten  is  considered  a  small  number  of  users  and  once 
ever  ten,  significant  performance  degradation  is  experi¬ 
enced.  [Ref.  18:  p.  13]  The  MIN  software  available  for 
transactions  include  TELNET,  the  Telecommunications  Network 
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Army  Operations 


Figure  3-1  HIHCCS/Joint  Deployment  Community  Belationship 


|  Erogratt  used  for  sassage  exchange  and  direct  access  to 

j  resources  of  remote  hosts,  the  File  Transfer  Service  (FTS) 

!  used  mainly  for  large  bulk  transfers  between  sites  (i.e., 

the  TPFCC  file  and  TPFDD  file  changes),  and  the 
‘Teleconference  (TLCF)  capability  which  simultaneously  links 
any  number  of  MIN  nodes  into  a  textual  exchange  conference. 
AUTODIN  is  the  general  message  exchange  system  which  may 
also  fce  used  for  query/response  activities  and  NACE  trans¬ 
fers  data  between  the  JDS  and  AUTODIN,  automatically 
formatting  the  messages  generated  by  JDS.  (Bef.  10:  p.  18] 

C.  AEP  GC IIS  ANE  CAPABILITIES 

The  Joint  Deployment  System  ADP  criteria  goals  include 
an  availability  cf  2h  hours  a  day,  7  days  a  week,  except  for 
scheduled  maintenance  and  unexpected  outages.  The  operation 
goal  is  SS*  for  routine  processing  and  99*  for  crisis  and 
exercise  operations.  The  deployment  data  base  is  resident 
at  J D A  with  the  major  backup  at  HEDCON.  The  JDA  and  REECCti 
computer  systems  are  comprised  of  four  processors  organized 
in  dual  configuration  with  shared  disk  drives,  colocated  in 
the  same  facility.  The  JDS  reliability  goal  for  *TBF  is  36 
hours  with  3TT3  cf  10  minutes.  When  fully  developed,  JDS 
will  fce  a  transaction-oriented  communications  system  capable 
of  real-time  processing  on  a  distributed  data  base  within 
the  WIN  environment.  (Bef.  10:  p.  32] 

The  JDS  computer  system  availability  not  only  depends  on 
the  best  computer  up/down  ratio;  ether  factors  include  the 
supporting  WWMCCS  system  software  such  as  the  Time-Sharing 
System  <TSS)  and  the  General  Comprehensive  Operating  System 
(GCOS) ,  the  JDS  software  which  includes  the  Remote  User's 
Eackage  tBUE),  and  HIN  availability.  All  cf  these  compo¬ 
nents  must  fce  availafcle  for  a  remote  user  to  access  the 
deployment  data  base.  JDS  will  allow  interfaces  with 
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appropriate  service  and  cot aand-unique  data  systems  for 
accurate  information  flow  among  the  joint  deployment 
community. 

The  JDS  rs  divided  into  5  procedural  subsystems: 

(1)  plan  generation  —  expansion  of  the  data  base 
for  inclusion  of  new  data 

(2)  plan  maintenance  —  modification  of  the  data 
tase  to  reflect  changing  resources  or  constraints 

(3)  execution  preparation  —  adjustments  tc  plan 
data  to  account  for  real  world  dates  and  require¬ 
ments 

(4)  scheduling  --  coordination  and  distribution  of 
transportation  schedules  developed  in  conjunction 
with  the  Ira rsporta ting  Operating  Agencies  (TCAs)  , 
i.e.,  Military  Airlift  Command  (MAC) ,  Military 
Traffic  Management  Command  ( MTMC)  ,  and  Military 
Sealift  Command  (MSC) 

(5)  movement  monitoring  —  reporting  cf  the  status 
of  the  deployment,  departures,  and  arrivals 

[Ref.  10:  p.  20] 

The  Jcir.t  Deployment  System  offers  the  joint  deployment 
community  five  processing  alternatives: 

(1)  Ti ~  ^  Sharing  System  (TSS)  --  simultaneous  access 
cf  the  computer  system  by  more  than  one  user 

(2)  batch  updating  --  primary  system  for  JDS  data 
case  control 

(3)  transaction  processing  --  data  base  updating 
through  one  cf  twenty-three  Transaction  Service 
Modules  (TSMs)  which  maintain  a  near  real-time 
information  flow  between  WIN  sites 

(4)  stand-alcne  programs  —  software  sent  over  the 
WIN  network  tc  update  the  JDS  data  base 

(5)  Remote  User’s  Package  (R CJP)  —  provides  the 
capability  tc  send  and  receive  transactions  from 
ether  WIN  sites  [Raf.  21:  p.  34] 
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Users  may  access  local  or  remote  deployment  data  bases 
using  ary  one  of  four  methods.  Twenty-two  on-lir.e  queries 
are  available  on  the  tins  sharing  system.  The  Management 
Data  Cue r y  System  (SECS)  for  retrievals  allows  the  user  tc 
originate  a  batch  process  for  information  retrieval  from  the 
Master  Force  List  (SFL)  fils  and  schedule  files.  The  HFL 
file  also  allows  users  without  the  3UP  capability  to 
initiate  information  queries.  Users  can  also  utilize  the 
automatic  scheduling  messages  package  to  automatically 
receive  movement  data  tor  the  next  twenty-four  hours  through 
the  NMCC  Automated  Control  Executive  (NACE).  [Hef.  21:  p« 
65] 

C.  DEVELOPMENT 

The  Joint  Deployment  System  is  being  developed  ir.  five 
stages.  The  Baseline  Stage  has  beet,  completed  and  JDS  now 
provides  service  to  the  joint  deployment  community.  The 
Initial  Operational  Capability  (IOC)  for  the  second  stage, 
which  includes  limited  on-line  update  and  query  features, 
distributed  processing  support  via  the  Remote  User's  Package 
(RU?)  ,  and  data  base  backup  at  R2DC3M,  was  achieved  December 
1982.  The  third  stage  incorporates  long-term  requirements 
definition  and  validation.  These  additional  requirements 
will  support  the  Crisis  Action  System  (CAS)  and  will  empha¬ 
size  such  things  as  multi-plan  support  and  no-plan  support. 
The  fourth  stage  is  Full  Operational  Capability  (FOC)  and 
the  ICC  is  presently  December  1  985.  Since  JDS  is  the  center 
of  the  conventional  Planning  and  Execution  (CPE)  functional 
family  of  the  WWMCCS  ADP  program,  the  fifth  stage,  Post-FCC, 
will  detail  the  JDS  integration  into  the  MIS  modernization 
Ftogra®.  (Hef.  10:  p.  78] 
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The  JDS  data  base  presently  contains  108  record  types 
chained  in  logical  record  relationships  in  the  Honeywell 
Integrated  Data  Store  (IDS)  structure.  The  data  includes 
information  on  forces,  ncnunit  personnel  and  cargo,  move¬ 
ment  ,  and  transportation.  The  JDS  is  a  conglomeration  cf 
175  application  programs  and  subprograms  which  maintain  and 
manipulate  the  deployment  data  base.  The  majority  cf  the 
JDS  software  works  or  menu- selection  and  pr e-def ined  display 
screens.  Although  the  entire  data  base  is  resident  at  the 
JDA,  various  deployment  community  members  will  maintain 
separate  data  bases  to  satisfy  unique  command  requirements 
and  command  and  control  functions.  Each  of  these  sites  will 
also  maintain  a  Data  Ease  Management  System  (DBMS)  and  local 
access  tc  the  main  data  base.  These  distributed  data  cases 
will  be  subsets  of  the  master  data  base  and  will  be  main¬ 
tained  concurrently  with  the  master  by  near-simultaneous 
(within  five  minutes)  distribution  of  data  transactions. 

This  distribution  will  significantly  reduce  WIN  activity  and 
network  performance  degradation  associated  with  large  data 
transfers.  The  distributed  data  bases  will  also  enhance  JDS 
survivability  by  providing  multiple  backup  locations  for  JDA 
functions.  [Hef.  10:  p.  25] 

I.  FOBCTIOHS 

One  cf  the  major  JDS  functions  is  to  provide  a  bridge 
between  deliberate  planning  and  time  sensitive  planning  and 
execution.  The  two  systems  utilized  during  these  procedures 
are  the  Joint  Operational  Planning  System  (JO?s)  and  the 
Unit  Status  and  Identification  Report  (UNITRE?)  System. 

JOPS  establishes  procedures  for  planning  and  executing 
deployments  during  peacetime  and  crisis  situations  as 
directed  by  JC3;  the  ONITREP  System  contains  the  location 
and  identification  of  actual  military  units  needed  during 


40 


the  planning  and  execution  phases  of  deployment.  The  JDS 
supplies  the  necessary  link  between  these  two  systems  by 
maintaining  an  up-to-date  deployment  data  base.  [Bef.  10: 
p.  9  ]  Figure  3.2  graphically  illustrates  the  JDS  connection 
between  deliberaxe  planning  and  time-sensitive  planning  and 
execution.  (Bef.  10:  p.  10] 

During  the  deliberate  planning  phase,  Time-Phased  Force 
Deployment  Data  (TPFDD)  files  are  developed  for  a  specific 
Operation  Plan  (OPLAN)  using  JOPS  and  U3ITBEP.  The  initial 
data  is  collected  from  supported  commanders  ar.d  service 
requirements.  The  JD&  holds  a  two-phase  conference  for 
refinement  of  the  data  and  then  the  TPFDD  is  incorporated 
into  the  JDS  data  base  for  that  specific  OPLAN.  This  method 
provides  the  primary  source  of  input  into  the  JDS.  Seme 
problems  with  these  procedures  are  the  time-consuming 
conferences  and  reviews  and  the  manual  manipulation  cf  the 
data.  (Eaf.  10:  p.  12] 


41 


Figure  3.2  Overview  of  Military  Planning  and  Deployment. 
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BIBOTI  USER '  S  PACKAGE 


Since  the  majority  of  JDS  users  are  remote  ar.d  the  File 
Transfer  Service  (PTS)  on  SIS  has  proven  to  be  slow  and 
unreliable,  th9  Joint  Deployment  Agency  developed  the  Remote 
User's  Package  (RUP)  to  offset  some  of  these  problems.  The 
ROP  is  installed  at  selected  BIS  sites  to  alleviate  some  0f 
the  network  overloading  caused  by  large  data  transfers. 

When  utilizing  the  Remote  User’s  Package,  r.o  direct  connec¬ 
tion  to  the  JDA  host  via  MIN  TELNET  is  required  to  access 
the  data  base.  [Bef.  21:  p.  26]  Since  the  RO?  permits  users 
to  input  update  and  query  transactions  via  their  own 
Time-Sharing  System  <TSS)  and  the  data  base  is  then  accessed 
through  MIN,  users  experience  a  significant  degradation  of 
cwn  TSS  response  time.  The  JDS  Remote  User's  Package 
includes  an  Interface  Processor  (JDSI?)  ,  an  Update  Processor 
(JDS UP)  ,  a  time-sharing  package,  and  a  batch  update 
capability.  [Ref..  IS:  p.  7  ] 

The  JESIP  provides  the  necessary  communications  protocol 
fcr  transaction  processing  between  two  MIN  sites.  The 
sending  site  JDSIP  breaks  bulk  files  into  individual  tran¬ 
sactions,  then  the  receiving  site  JDSI?  accepts  each 
transaction  and  passes  it  to  the  JDS  if  a  MIN  connection  is 
available  or  holds  the  transaction  until  a  connection  is 
made.  An  acknowledgement  is  necessary  from  the  receiver 
before  the  next  transaction  (packet)  is  sent.  The  Remote 
User's  Package  essentially  transforms  the  WWMCCS 
Intercomputer  Network  into  a  transaction  processing  system, 
as  was  the  original  design  goal  for  WIN.  The  capabiltiy  r.ow 
exists  fcr  transaction  update  processing  between  two  MIN 
sites  in  near-real  time  without  dependence  on  a  MIN 
connection  to  the  JDS.  [Ref.  19:  p.  9] 
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The  JESIP  of  the  receiving  sire  forwards  the  *ra  reac¬ 
tions  to  the  JDS  Update  Processor  (JDSU?)  for  individual 
inclusion  into  the  data  base.  The  JDSUP  is  capable  ci 
receiving  input  transactions  from  the  time-sharing  or  batch 
system,  SIN  via  the  JDSIP  and  FTS  capability,  ar.d  AUTODIN 
via  the  N  ACE  processors.  The  Update  Processor  provides 
dynamic  recovery  check  points  during  processing  without  task 
interruption.  If  necessary,  transaction  processing  recovery 
is  achieved  after  a  communications  interruption  using  these 
checkpoints,  thereby  no  longer  requiring  the  complete 
reinitialization  of  the  task.  [Ref.  19:  p.  9] 

Although  JDA-generated  software  has  greatly  improved  JDS 
performance,  particularly  in  the  WIN  arena,  additional 
improvements  are  necessary.  JDS  should  be  supported  by 
software  which  requires  a  minimum  amount  of  training  and 
skills  due  to  the  computer  experience  of  most  users;  for 
instance,  JCS  action  officers.  Users  have  recommended  "he 
information  displays  be  modified  to  remove  the  time-frame 
distircticn  cf  •deliberate*  or  'crisis*  planning.  Although 
the  data  is  now  maintained  guarterly  by  the  Command  and 
Control  Technical  Center  (CCTC)  ,  part  of  DCA,  the  JDS 
deployment  data  base  should  move  towards  real-time  mainte¬ 
nance  tc  constantly  provide  a  current  deployment  situation 
data  base  resident  at  JDA.  [Ref.  10:  p.  13] 

Additional  areas  for  general  system  improvement  include: 

(1)  revising  man-machine  interfaces  for  simplifica¬ 
tion 

(2)  aggregating  information  for  senior  level 
managers  on  general  JDS  capabilities 

(3)  insuring  more  accurate  and  timely  data  collec¬ 
tion 

(4)  developing  standard  data  definitions 

(5)  enhancing  the  recovery  and  backup  facilities 

[B«f.  10:  p.  19] 
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If.  HIM CCS /JDS  PEBPOBHAHCE 


As  previously  discussed,  the  information  flow  between 
the  MCA  and  military  forces  depends  upon  a  reliable,  secure, 
and  survivable  intercomputer  network.  The  WWMCCS 
Intercomputer  network  (WIN)  was  designed  to  provide  exchange 
of  information  through  computer-to-computer  and  remote 
terminal-to-computer  processing  using  distributed  data  base 
concepts  and  workload  sharing  techniques.  (Ref.  5:  p.  42] 
WWMCCS  evclved  through  the  early  years  as  services  developed 
hardware  and  software  to  meet  unique  require®  ts.  Eased  on 
the  evolutionary  approach  to  systems  development,  WWMCCS 
should  evolve  through  requirements  specifications  as  opposed 
to  the  traditional  system  acquisition  approach.  This  theory 
is  supported  by  a  lack  of  specific  C3  system  criteria; 
poorly  understood  C3  systems  concepts;  language  barriers 
between  the  policy  makers,  planners,  and  commanders;  and  the 
nebulous  framework  fcr  C3  systems  evaluation.  [Ref.  5:  p. 
16]  There  are  numerous  systems  other  than  C3  systems  which 
suffer  frcm  cne  cr  acre  of  the  problems  mentioned.  For 
instance,  any  highly  specialized  system  will  lively  experi¬ 
ence  barriers  amcng  technologists  and  users. 

As  proven  with  the  early  WWMCCS,  allowing  users  to 
develop  small,  unique  systems  independently,  precludes  the 
integration  of  these  systems  into  a  responsive,  larger 
system.  Obviously,  interoperability  was  not  the  primary 
concern  fcr  these  individual  funding  efforts.  Twenty  years 
later,  WWMCCS  remains  somewhat  fragmented  due  to  the  absence 
cf  a  centralized,  long-range  plan  for  the  management  and 
budget  control  of  WWMCCS  and  the  Defense  programs  affecting 
WWMCCS.  With  the  WWMCCS  Information  System  (WIS) ,  a  Joint 
Program  Manager  (JPM)  Office  was  established  to  provide 


centralized  management  for  all  aspects  of  ■'.he  WHMCCS  moder¬ 
nization  program. 

4.  SCFTS1HE 

The  computer  operating  system  utilized  with  the 
Honeywell  equipment  is  the  General  Comprehensive  Operating 
Systeir  (GCOS)  designed  by  Honeywell.  Honeywell  also  disrri- 
butes  this  operating  system  to  civilian  customers  but  the 
Command  and  Control  Technical  Center  must  extensively  modify 
each  GCOS  release  for  security  additions  and  unique  WWMCCS 
Software  sc  the  GCOS  used  within  the  tfWMCCS  coma  unity  is 
consistently  several  years  behind  the  current  civilian 
version.  GCOS  was  developed  to  support  a  single-site  and 
batch-oriented  user  community  and  has  proven  very  successful 
in  such  situations.  Present  day  C3  system  requirements 
however,  demand  an  online  interactive  processing  capability. 
Hhile  modifications  to  the  Honeywell  hardware  ani  software 
have  improved  performance,  the  basic  circuitry  is  designed 
for  batch  processing  and  optimal  performance  will  ret  be 
achieved  in  an  online  interactive  environment. 

With  any  large  data  base  system,  a  Data  Base  Management 
System  (DEMS)  will  be  developed  to  allow  easy  retrieval  and 
updating  of  the  data  base.  Generally,  these  management 
systems  are  user-friendly  and  require  minimal  technical 
expertise  fer  successful  use.  The  DBMS  used  with  wwtiCCS  is 
the  HtiMCCS  Cata  Management  System  (WBDMS).  Since  SJWDMS 
reside,  cn  the  Honeywell  equipment,  it  relies  on  the  GCOS 
operating  system;  therefore  WWDSS  was  designed  around  a 
batch-oriented  architecture.  HWDMS  uses  GCOS  to  access 
files  for  retrievals  and  updates.  Because  of  the  ineffi¬ 
ciencies  of  the  military  version  of  GCOS  in  transferring 
data  in  and  cat  cf  primary  memory,  the  performance  of  WHDWS 
is  adversely  affected.  (Bef.  5:  p.  25] 
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Beports  on  the  user-friendly  aspect  of  WHDHS  have  r.ct 
teen  favorable.  For  the  most  part,  the  wwdhs  language  is 
oriented  towards  the  more  technical  personnel  and  is  consid¬ 
ered  too  detailed  for  the  average  BHMCCS  user  with  minimum 
computer  training.  Consequently,  users  are  not  likely  to 
pursue  the  management  system  capabilities  beyond  standard 
procedures  and  WBDMS*  full  facilities  remained  unused.  For 
the  community  to  exploit  the  systems  and  capabilities  avai¬ 
lable  in  BMMCCS,  a  user-friendly  and  responsive  DBMS  is  a 
necessity.  Since  the  concepts  of  a  distributed  databse 
management  system  are  new,  a  rsliaole  query  language  could 
suffice  during  the  development  interim.  It  should  require 
minimum  computer  experience  and  a  minimum  amount  of  special 
training. 

The  need  for  a  Multi-Level  Security  system  will  not  be 
satisfied  utilizing  the  the  current  HBMCCS  Honeywell  equip¬ 
ment  since  this  design  incorporates  only  two  machine  states, 
or  rings.  The  Master  state  accomplishes  the  kernel  func¬ 
tions  cf  the  operating  system,  password  validation  and  data 
requests,  as  well  as  the  functions  for  scheduling  and  allo¬ 
cation  cf  resources.  The  second  state  is  for  user 
applications  programs,  referred  to  as  the  Slave  state. 

[Bef .  5:  p.  29] 

Since  the  security  protection  procedures,  all  system 
software,  and  the  resource  allocation  procedures  reside  in 
the  same  ring,  access  to  the  specified  ring  area  is  coxmon 
to  all  users  with  access  to  any  one  section  of  that  ring. 

The  current  theory  is  that,  under  this  scheme,  any  gccd 
systems  programmer  3bculd  be  able  to  penetrate  the  kernel 
section  and  gain  access  to  all  passwords  and  security 
checking  procedures. 

Security  alternatives  to  a  MLS  system  are  dedicated 
computers,  scheduled  operations,  and  system-high  security 
cperaticcs.  With  dedicated  computers,  a  separate  computer 
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is  reguired  for  each  security  level  and  individual  data 
bases  are  reguired  fcr  each  application  requirement  within 
the  different  security  levels.  The  scheduled  operations 
■ethod  insures  all  data  per  security  level  is  processed  at 
separate  tixes.  This  restricts  users  of  different  security 
levels  tc  computer  availability.  The  most  difficult  aspect 
to  this  aethcd  of  secure  processing  is  the  sanitization 
necessary  between  security  level  processing  periods.  The 
entire  system  environment  must  be  modified,  both  the  machine 
and  physical  facility.  In  addition,  communications  lines 
must  be  broken,  disk  packs  must  be  exchanged  for  the  diffe¬ 
rent  security  levels,  and  main  memory  cleared.  This 
procedure  averages  ots  to  two  hours  to  complete.  [Ref.  5: 

F-  28] 

The  third  alternative,  system-high  security  operations, 
is  primarily  used  throughout  the  WWMCCS  community.  With 
systen-high  operations,  all  personnel,  physical  space,  and 
equipment  must  be  approved  for  the  highest  security  level  of 
the  information  being  processed.  The  biggest  disadvantage 
to  this  method  is  the  restriction  it  places  on  the  sharing 
cf  secure  computer  resources.  In  addition,  this  method 
becomes  costly  in  terms  of  physical  security  and  personnel 
clearances.  The  system-high  security  approach,  if  imple¬ 
mented  correctly,  will  satisfy  security  level  requirements 
but  dees  not  address  the  need-to-know  issue.  [Ref.  5:  p. 

28] 

E.  HABDiARE 

The  availability  of  an  electric  power  source  greatly 
affects  the  reliability  and  survivability  of  a  computer 
network  such  as  the  WWHCCS  Intercomputer  Network  (Hi N) .  For 
the  current  WIN ,  there  exists  nc  standard  criteria  for  the 
availability  of  electric  power.  If  electric  power  is 
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disrupted  cr  the  air-conditioning  damaged,  data  processing 
capabilities  are  totally  lost  or,  at  a  minimum,  severely 
degraded.  Only  a  few  WIN  sites  have  a  reliable  backup  power 
source  or  redundant  computer  system.  The  National  Military 
Command  Center  (NMCC)  maintains  two  independent  power 
sources  for  its  computer  system.  This  system  affords 
protection  against  various  local  power  blackouts  and  irregu¬ 
larities  in  the  commercial  power  system.  [Bef.  5:  p.  29] 

The  NMCC  also  maintains  a  totally  redundant  computer  system, 
hardware  and  software,  located  at  the  Alternate  National 
Military  Command  Center  (ANMCC)  ,  which  has  an  internal  power 
generating  capability.  In  early  WWMCCS  years,  the  ANMCC  was 
considered  hardened  and  fully  self-supporting,  but  the 
alternate  site  is  nc  longer  considered  hardened  against  the 
current  threat.  A  few  other  large  WWMCCS  sites  utilizing 
commercial  power  are  also  armed  with  an  internal  power 
generating  capability,  for  instance,  the  North  American  Air 
Defense  Command  (NOS AD)  and  the  Strategic  Air  Command  (SAC)  . 
Most  ether  SWMCCS  sites  have  no  reliable  backup  power 
source. 

Presently  the  NHCC  has,  of  course,  the  most  viable 
alternate  computer  system  --  both  redundant  and  remote. 

Other  sites  maintain  redundant  data  bases  but  usually  in 
close  proximity.  For  example,  the  Joint  Deployment  Agency 
maintains  a  backup  JDS  data  base  at  the  Readiness  Command 
(REDCCM)  but  which  is  physically  located  at  the  same 
facility. 

C.  Ill  HAGUE  82 

During  the  period  1  March  to  5  March  1982,  the  JCS 
conducted  a  WWMCCS  exercise,  ITT  LEAGUE  82.  The  exercise 
was  designed  to  evaluate  defense  operations  run  from  the 
H8CC  at  the  Pentagon,  then  relocated  to  the  alternate 
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command  center,  -the  ANHCC.  As  the  exercise  progressed,  win 
performance  dropped  and  response  times  reached  an 
unacceptable  level.  A  DCA/CCTC  sponsored  IVY  LEAGUE 
Analysis  Task  Force  was  organized  to  analyze  the  performance 
of  the  WWMCCS  ADP  system  and  network,  with  concentration  on 
the  particular  problems  encountered  during  the  IVY  LEAGUE 
exercise.  [  Eef .  22s  p.  1-1] 

The  Task  Force  focused  its  analysis  on  the  four  major 
sites  where  “-he  slowdown  condition  was  most  prevalent:  the 
NNCC  Beadiness  System,  the  ANMCC,  HEDCOM,  and  the  JDA. 

These  four  sites  were  not  all  the  WIN  nodes  participating  in 
the  exercise,  but  it  was  felt  these  sites  were  indicative  of 
overall  WIN  performance  during  IVY  LEAGUE  82.  Information 
was  collected  from  cn-site  exercise  personnel,  manual  legs 
updated  throughout  the  exercise,  computer  generated  list¬ 
ings,  and  WWMCCS  computer  system  console  logs  from  the 
participating  sites.  (Hef.  22:  p.  v  ] 

The  IVY  LEAGUE  Task  Force  revealed  several  major  factors 
contributing  to  the  WIN  degradation: 

(1)  excessive  communications  processor  loading 

(2)  communications  subnetwork  fragmentation 

(3)  host  computer  resource  contention 

(4)  software  resource  contention 

(5)  management  of  computer  operations 

Each  cf  these  will  be  discussed  in  the  following  sections 
with  their  impact  on  JDS  performance. 

D.  COHHUSICATIONS  PBOCESSOR  LOADING 

The  successful  operation  of  the  WIN  network  depends  on 
an  unconstrained  flow  of  data  between  the  computer  system 
and  the  network.  A  communications  processor  is  used  on  the 
network  to  coordinate  inputs  from  remote  terminals  and  send 
them  to  the  host  system;  it  also  receives  outputs  from  the 
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computer  system  and  sends  them  to  the  correct  user.  The 
communications  processor  handles  the  connection  from  the 
host  computer  system  to  the  network.  The  Honeywell  Datanet 
355  (EN  355)  is  the  ccmm unications  processor  used  throughout 
the  HftHCCS  community. 

The  design  of  the  Datanet  requires  sufficient  available 
memory  tc  process  message  traffic;  otherwise  the  Datanet  may 
restrict  the  flow  of  traffic  from  the  host  to  the  network 
and  from  remote  sites  to  the  host  througa  unsatisfactory 
terminal  response  time  and  slow  file  transfers.  The  block 
of  memory  allocated  for  message  processing  is  subdivided 
into  sections  called  fcuffars.  Buffer  size  is  dependent  on 
the  type  and  number  cf  connections  to  the  Datanet.  The 
greater  the  number  of  connections,  the  lower  the  available 
memory  and  the  lower  the  buffer  size.  WIN  connections  to 
the  Datanet  must  contend  for  buffer  space  with  remote 
processors,  AUTOEIN  connections,  and  the  local  terminals. 
CBef .  22;  p.  2-1  ] 

During  IVY  LEAGUE  82,  when  the  Datanet  became  over¬ 
loaded,  users  experienced  up  to  ten  second  pauses  for  system 
response.  Seme  of  this  was  attributable  to  Datanet  eve r- 
ccnf iguraticn  --  too  many  connections  tc  one  Datanet.  At 
JDA,  all  115  local  terminals  and  the  SIS  connection  were 
served  by  the  one  Datanet.  In  some  cases,  several  terminals 
shared  one  line  into  the  communications  processor  which 
further  hindered  terminal  response  time.  In  addition  tc  the 
terminal  overloading,  this  same  Datanet  also  served  the 
AUTODIN  interface  at  all  four  sites  reviewed.  [  Bef .  22:  p« 
2-1]  With  this  Datanet  configuration,  any  terminal  discon¬ 
nect  from  the  system  or  any  Datanet  failure  affects  all 
connected  terminals,  both  local  and  remote.  Considering  the 
large  number  of  terminals  connected,  the  chance  of  a  Datane4- 
failure  or  system  reinitialization  (reboot)  to  clear 
terminal  cr  WIN  problems  is  extremely  high.  Figure  4.1 
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graphically  depicts  cser-de  pendence  on  the  DN  355/Hcst  link. 

[Bef.  8:  p.  3] 


Figure  4.1  JDA  Configuration. 

During  periods  of  particularly  bad  psrformar.ee  in  IVY 
LEAGUE  82,  computer  data  dumps  were  taker,  from  the  REECCM 
Datanet.  JEA  Datanet  dumps  were  not  available,  but  the 
REDCOM  configuration  was  considered  similar  to  that  of  JD A 
with  139  local  terminals  connected  to  the  one  Datanet.  Data 
retrieved  revealed  4,490  data  transfer  requests  denied 
during  a  17-hour  period  because  of  insufficient  buffer 
space.  During  a  separate  22-hour  period,  an  additional 
4,651  data  transfers  were  denied  due  to  lack  cf  buffer 
space.  These  nuvbers  only  reflect  Datanet  denials,  local 
Interface  Message  Processor  (IMP)  and  terminal  malfunctions 
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■ay  also  have  occurred.  During  IVY  LEAGUE  82,  the  JDA  host 
computer  received  an  average  of  150,000  transactions  par 
day.  Specifically,  on  2  March,  JDA  processed  252,864  tran¬ 
sactions  and  87,417  transactions  were  processed  cn  4  March. 

(Ref.  22:  p.  2-2] 

A  net  her  hinderance  to  Datanet  performance  was  operator 
reboots  cf  the  Datanet.  Operations  would  frequently  reini¬ 
tialize  the  Datanet  in  an  attempt  to  free  blocked  terminals 
or  solve  WIN  problems  and  various  other  abnormalities  occur¬ 
ring  in  the  network.  [Ref.  22:  p.  2-1]  Although  the 
specific  impact  cf  these  Datanet  restarts  were  net  analyzed, 
they  obviously  affected  WIN  performance.  For  instance,  the 
Joint  Deployment  System  tranfer  s -TPFDD  files  and  TPFDD  file 
changes  to  remote  sites  through  the  WIN  FTS.  If  a  Datanet 
reboot  occurs  during  this  time,  the  file  transfer  must  be 
recovered.  Previous  to  the  development  of  the  Remote  User's 
Package  (EUF),  transaction  recovery  meant  file  transfer 
reinitialization.  Now,  the  JDS  Update  Processor  (JPSUF) 
dynamically  generates  checkpoints  throughout  the  transfer  to 
allow  file  transfer  recovery  at  the  point  of  disconnection. 

The  WWMCCS  community  employs  Datanet  performance  moni¬ 
toring  software  to  warn  of  possible  Datanet  overload.  This 
monitoring  software  requires  approximately  2,  500  words  cf 
memory  which  further  reduces  the  Datanet  memory  available 
for  message  processing  buffers.  Consequently,  at  all  four 
sites  included  in  the  analysis,  the  monitoring  software  was 
net  in  execution.  [Ref.  22:  p.  2-1] 

E.  NETWORK  FRAGMENTATION 

As  discussed  in  the  previous  section,  the  WWMCCS  network 
is  very  susceptible  to  interruptions  occuring  within  the 
lines  cf  communications.  Any  network  configuration  changes, 
component  outages,  or  circuit  failures  will  cause 
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fragmentation  of  the  network  into  subnetworks,  • 
degrading  perf oraan ce.  [Ref.  22:  p.  3-1]  Each  wwmccs  host 
computer  involved  in  the  WWMCCS  Intercomputer  Network  is 
linked  tc  a  Honeywell  minicomputer  called  an  Interface 
Message  Processor  (IMP),  and  the  various  IMPS  are  then 
interconnected. 

During  IVY  LEAGUE  82,  the  Network  Operations  Center 
(NOC)  and  DC  A  Operations  Center  (DCAOC)  were  relocated  tc 
the  alternate  command  center,  the  ANMCC.  Tc  provide 
continued  support  for  these  nodes  on  the  MIN  subnetwork,  the 
master  IMP,  normally  at  the  Pentagon,  was  logically  recon¬ 
figured  tc  the  backup  facility  at  the  Command  and  Control 
Technical  Center  (CCTC)  ,  Reston.  Changes  were  necessary 
within  the  MIN  subnetwork  due  to  the  backup  IMP'S  limita¬ 
tions  and  circuit  availability.  The  major  modification  was 
the  deletion  of  the  link  from  the  master  IMP  tc  the  IMP  at 
Headquarters,  Atlantic  Command.  As  the  exercise  progressed, 
it  became  evident  that  the  loss  of  this  one  particular  link 
proved  tc  be  a  major  factor  in  network  fragmentation. 

Curing  these  periods  cf  fragmentation,  the  exchange  cf  data 
between  WIN  sites  was  totally  disrupted.  [Ref.  22:  p.  3-2] 

Although  the  IMP  and  circuit  outages  were  usually  short, 
these,  coupled  with  the  major  configuration  changes, 
severely  degraded  KIN  performance.  For  instance  cn  2  March, 
88  circuit  outages  occured  for  a  total  of  5.13  hours 
down-time.  Later  in  the  exercise  on  4  March,  a  sum  loss  of 
7.72  hours  was  felt  during  138  circuit  outages.  For  the 
entire  IVY  LEAGUE  82  exercise,  476  line  outages  occured  with 
65  extending  over  10  minutes,  22  of  these  outages  were  the 
result  of  required  cryptographic  key  changes.  Key  changes 
were  a  frequent  cause  for  circuits  displaced  from  normal 
activities.  IMP  outages  for  the  exercise  totaled  334  with 
52  lasting  over  10  minutes:  77  at  6.63  ncurs  cn  2  March  and 
82  at  7.62  hours  on  4  March.  [Ref.  22:  p.  3-6] 
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During  IVY  LEAGUE  82,  numerous  cases  of  host  resource 
misuse  occurred  in  areas  such  as  primary  memory  allocation, 
job  priority  assignment,  and  improper  implementation  of  WIN 
software.  These  conflicts  severely  limited  the  host  system 
performance.  The  Analysis  Task  Force  studied  these  problems 
at  the  NWCC  Readiness  and  AMHCC  computer  systems  only,  bur 
it  was  felt  similar  situations  existed  at  numerous  ether 
WWMCCS  sites.  (Bef.  22:  p.  4-1] 

The  NKCC  WWMCCS  site  is  segregated  into  two  destine4: 
computer  systems:  Readiness  and  Support.  The  Readiness 
System  is  designed  fer  the  operation  of  WWMCCS  standard 
software  and  other  site-unique  software  that  has  previously 
teen  tested  and  is  new  in  production.  The  NMCC  Support 
System  is  an  identical  configuration  to  the  Readiness  system 
and  exists  fer  the  development  and  testing  of  new  software. 
Cnly  the  Readiness  System  participates  m  JCS  exercises  as 
the  Support  System  continues  to  support  daily  operations. 
Priorities  fall  so  that  the  Support  System  may  be  sacrificed 
to  maintain  the  performance  of  the  Readiness  System. 

With  cnly  fully  operational  software  allowed  on  the  NMCC 
Readiness  System,  the  percentage  of  aborted  jobs  is  expected 
to  be  small.  During  the  exercise,  the  amount  cf  computer 
resources  expanded  cr  jobs  which  ultimately  aborted  was 
unacceptably  high.  Some  aborts  were  due  to  magnetic  tape 
and  various  ether  hardware  problems,  out  an  undesirable 
number  were  caused  by  software  still  in  the  developmental 
stage.  (Bef.  22:  p.  4-2]  Prior  to  a  new  WWMCCS  software 
release,  the  temptation  for  programmers  to  use  the  Readiness 
System  as  a  testbed  fer  application  system  modifications  is 
high.  The  response  time  is  decidedly  better  cn  the 
Readiness  System  because  of  decreased  aoorts  and  code  optim¬ 
ization.  Guidelines  for  testing  state  all  systems  resident 
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on  the  Readiness  system  to  fce  tested  and/or  modified  will  be 
transferred  to  the  Support  System.  After  verification  with 
the  new  HWMCCS  software,  the  modified  system  will  then 
replace  the  old  system  on  the  Readiness  computer.  The  idea, 
of  course,  is  to  preserve  the  Readiness  computer  m  both 
time  and  space  r  eguirsments  for  crisis/sxsrcise  support  and 
employ  a  second  system  for  the  heavy  processing  ar.d  tne 
usually  large  space  consumption  of  software  development. 

Beth  systems  studied,  the  NMCC  Readiness  and  the  AHMCC 
system,  suffered  from  a  lack  of  available  memory  fer 
processinq.  In  particular,  on  2  March  memory  shortages 
severely  corstrained  processing  capabilities  for  a  five  heur 
period.  Under  the  current  WWMCCS  AD?,  it  is  possible  tc 
dynamically  reconfigure  a  system  without  completely  bringing 
it  off-line;  for  example,  allowing  the  addition  of  memory  to 
the  host  computer  system  during  an  exercise,  [fief.  22:  p. 
4-1]  Although  infreguently  done,  memory  may  b<=  acquiree  from 
the  NMCC  Support  System  to  improve  the  per fcrmance  cf  the 
Readiress  System. 

A  standard  WWMCCS  program  size  is  approximately  60K  (60 
x  1024  bytes).  Any  cue  application  program  requiring  more 
than  60K  or  a  large  amount  of  CPU  time,  should  be  remodeled 
to  include  code  optimization  and  some  method  cf  memory 
overlays  or  paging.  [Bef.  22:  p.  4-1] 

In  addition  to  large  memory  utilization,  numerous  jobs 
with  high  priorities  running  simultaneously  will  affect 
system  performance.  Honeywell  supports  an  urgency  system 
for  determining  job  priorities  --  urgencies  may  vary  from 
zero  to  63.  Typically,  urgencies  of  31  and  below  are  used 
for  user  application  programs;  for  example,  routine  batch 
and  TSS  jebs  are  assigned  an  urgency  of  5.  Urgencies  above 
30  are  reserved  for  system  software  applications  and  special 
production  runs.  Urgencies  higher  than  50  support  system 
programs  such  as  TLCF,  FTS,  and  other  51  IN  software. 
tHef.  22:  p.  4-2] 
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Statistics  show  approximately  thirty  percent  of  all 
activities  processed  cn  the  ANHCC  computer  system  during  the 
exercise  had  urgency  levels  greater  than  or  equal  to  the 
urgency  levels  of  system  functions.  Software  such  as  TSS 
and  WIH  have  urgencies  from  50  to  SO  to  allow  primary  access 
to  the  processor.  During  IVY  LEAGUE  62,  this  software  was 
competing  with  user  application  software  for  computer 
resources  because  of  unjustified  high  user  application 
urgencies.  [Bef.  22:  p.  4-1] 

The  KWMCCS  systea  consols  operator  has  the  ability  to 
override  system  prescribed  urgencies.  This  is  usually 
accomplished  on  a  case  by  case  basis  for  ad-hcc  production 
runs.  Any  system  requiring  a  large  block  of  memory, 
substantial  CPU  time,  or  lengthy  input/output  processing 
will  normally  be  awarded  a  lower  urgency,  causing  it  to 
remain  in  the  system  a  relatively  longer  length  of  time. 

When  the  urgencies  cf  these  systems  are  bumped  to  higher 
levels,  whether  justified  or  r.ot,  they  compete  with  system 
software,  usually  large  time-consuming  systems  themselves 
and  the  'molasses  condition'  occurs  --  total  system  slow¬ 
down.  Ac  inordinate  amount  cf  automated  bookkeeping  is 
necessary  for  proper  resource  availability  and  the  processor 
becomes  overloaded.  When  this  condition  occurs,  known  as 
thrashing,  the  effectiveness  of  the  Honeywell  urgency  system 
drops  to  zero. 

The  cumulative  affect  of  all  the  above  mentioned  situa¬ 
tions  equals  increased  user  response  tnae  and  user 
frustration.  During  normal  NMCC  operations,  TSS  response 
time  averages  five  tc  seven  seconds;  during  heavy  usage, 
exercises  or  crises,  response  time  increases  incrementally 
by  approximately  three  seconds  until  total  system  slowdown 


BIN  software  is  ret  always  the  • victim •  of  poor  WIN 
performance.  Soae  software,  booh  systems  software  and 
application  systems,  contribute  to  the  increase  in  host 
system  processing  requirements.  When  these  requirements 
exceed  system  capabilities,  support  of  local  ar.d  network 
operation  decreases. 

Seme  of  the  SIN  system  software  particularly  affected  by 
degraded  network  performance  includes: 

(1)  Teleconferencing  (TLC?)  System 

(2)  Pile  Transfer  Service  (FTS) 

(3)  Tslecommunciati  ens  program  (TELNET)  .  [Bef.  22: 

p.  6-1] 

The  Teleconferencing  capability  in  WIN  allows  users  to 
rejoin  the  conference  and  request  a  transcript  file  of 
actions  since  that  site's  last  log-on.  These  files  are 
spooled  to  the  printer  at  a  hijh  urgency  for  speedy 
printing.  During  IVY  LEAGUE  82,  the  large  number  of  tran¬ 
script  file  requests  severely  impacted  the  performance  cf 
the  system  hosting  the  teleconference. 

The  File  Transfer  Service  employed  in  the  win  utilizes  a 
dynamic  memory  management  scheme  to  maintain  an  available 
memory  level  between  the  minimum  and  maximum  guidelines. 

The  management  system  constantly  allocates  ar.d  deallocates 
sections  cf  memory  as  small  as  IK  to  sustain  an  acceptable 
memory  level.  This  continuous  processing  requirement  places 
a  heavy  lead  on  the  host  processor.  Also,  during  a  file 
transfer,  FTS  reads  and  writes  one  Little  Link  ( LLINK)  cf 
data  at  a  time,  320  words.  This  limits  possible  transfer 
rates  and  FTS  effectiveness.  [Bef.  22:  p.  6-1] 

TELNET  uses  software  similar  to  the  FTS  memory  manage¬ 
ment  software.  Although  this  imposes  additional  loading  on 
the  processing  system,  the  contribution  to  system  leading  is 
not  as  significant  as  FTS  or  TLCF.  [Ref.  22:  p.  6-1] 
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G.  JES  RESOURCE  COMEHTIOH 

large  software  applications  used  over  the  HtfMCCS 
network,  such  as  the  Joint  Deployment  Systei,  need  tc  be 
concerned  about  resource  requirements  and  operational  effi¬ 
ciency.  Since  such  a  wide  degree  of  diversity  exists  among 
application  systems,  no  guidelines  for  standardization  cf 
new  HVMCCS  software  have  beer  established;  therefore,  these 
issues  axe  left  to  the  developing  agency.  For  instance,  the 
Joint  Deployment  System  maintains  two  interactive  subsys¬ 
tems,  the  JDSIP  and  JDSOP  as  part  of  the  Remote  User’s 
Package  (RUF).  The  Analysis  Task  Force  contends  these  two 
subsystems  fail  to  take  the  best  advantage  of  the  standard 
HWJ1CCS  software  features  and  consequently  generate  substan¬ 
tial  overhead  for  the  processor.  After  analysis  of  IVY 
LEAGUE  82,  the  need  was  evident  to  redesign  portions  cf  the 
JDS  software  to  insure  more  efficient  processing  and 
overhead  minimization.  [Ref.  22:  p.  6-3] 

The  operation  of  the  JDSIP  caused  aoticable  degradation 
during  the  exercise.  The  Interface  Processor  subsystem 
requires  28K  to  process  and  runs  with  an  urgency  of  51.  The 
JDSIE  will  remain  in  memory  as  long  as  it  is  processing 
transactions.  When  the  processor  is  not  required,  i.e.,  no 
transactions  to  be  processed,  the  JDSIP  will  place  itself  in 
a  ‘sleep  state’  —  degrading  its  urgency  tc  zero  which 
immediately  allows  it  to  be  swapped  out  cf  the  system  at  the 
next  memory  allocation  request.  Actually,  this  should  be 
very  efficient  use  of  memory,  or  at  least  28K.  The  problem 
arises  in  waking  up  the  JDSIP.  Since  the  subsystem  has  no 
means  of  determining  when  the  next  transaction  will  be 
received,  the  JDSIP  periodically,  about  every  two  tc  three 
seconds,  resets  its  urgency  back  to  51  which  returns  it  tc 
memory  where  it  can  check  for  transactions  to  be  processed. 
If  no  transactions  are  waiting,  the  urgency  is  raturned  to 
zero  and  the  cycle  repeats.  [Ref.  22:  p.  6-3] 
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This  scheme  is  at  its  worst  when  JDS  is  rarely  used  on  a 
given  system.  The  JESIP  siaply  fluctuazes  from  mass  storage 
to  primary  msaory  with  no  advantage.  This  swapping  back  and 
forth  creates  unnecessary  overhead  processing  and  can  seri¬ 
ously  degrade  network  performance.  Case  in  point:  cn  1 
March,  during  IVY  LEAGUE  82,  the  JDSIP  was  swapped  a  total 
cf  412  times  in  an  eight-minute  period,  from  1355  to  1403. 
(Ref.  22:  p.  6-3] 

The  JDS  Update  Processor  (JDSU?)  poses  a  similar  situa¬ 
tion.  The  JCSUP  requires  only  9K  to  process  and  runs  at  an 
urgency  cf  55.  During  certain  processing  periods,  the  JDSUP 
must  reguest  a  single  block  cf  50K  of  memory.  When  this 
request  enters  the  system,  the  system  will  immediately  rear¬ 
range  its  memory  to  accommodate  the  request  from  such  a  high 
priority  jot.  Usually,  a  system  interruption  is  evident 
After  the  JDSUP  has  completed  that  procass,  the  50K  is 
returned  to  memory;  however,  the  JDSU?  in  general  immedi¬ 
ately  asks  for  another  single  block  of  50K  to  continue 
processing.  (Ref.  22:  p.  6-3] 

The  allocation  and  deallocation  of  this  50K  of  memory 
proved  tc  b*  detrimental  during  the  IVY  LEAGUE  exercise.  Or. 
2  March,  JDSUP  requested  50K  at  0120,  released  the  msmcry  at 
0122,  and  requested  another  50K  block  at  0125.  This  cycle 
cf  requesf-rel ease-request  was  repeated  during  the  C330-0340 
time  pericd  that  same  day.  (Bef.  22:  p.  6-3] 

B.  MANAGEMENT  OF  COMPUTER  OPERATIONS 

During  IVY  LEAGUE  82,  it  became  evident  that  hardware 
and  software  problems  were  net  entirely  responsible  fer  the 
C3  system  degradaticr.  The  overall  management  and  control 
of  the  network  and  host  system  also  contributed  to  deficient 
performance. 
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As  part  of  the  normal  operations  of  all  WIN  sites,  hard¬ 
ware  such  as  the  host  computer  systaa,  the  Datanet,  and  the 
IMPS  are  reinitialized  in  an  attempt  to  solve  various  prob¬ 
lems.  These  reboots  interrupt  network  performance  and  can 
impact  local  user  operations.  In  addition  to  unexpected 
down  time  and  reboots,  scheduled  outages  occur  at  all  sites. 
The  WWHCCS  community  has  no  standard  guidelines  for  the 
scheduling  cf  these  outages.  Frequently,  these  unscheduled 
downtimes  are  not  justified;  for  instance,  durino  the  exer¬ 
cise,  a  Eatanet  was  rebooted  to  allow  a  single  user  access 
to  a  particular  system  for  a  local  processing  requirement. 
This  reboot  affected  all  users  on  that  subnetwork. 

On  3  March,  the  ANMCC  discontinued  service  to  remote 
users  because  of  an  apparent  memory  shortage  problem. 
According  tc  VIDEO,  an  online  display  system  which  allows 
monitoring  cf  system  status,  minimum  work  was  being 
processed  because  of  a  lack  of  available  memory.  The  after 
exercise  analysis  however,  revealed  approximately  150K  cf 
memory  available  during  that  time  frame.  The  discrepancy 
occurred  due  tc  improper  use  of  the  VIDEO  system.  This 
system  is  designed  tc  provide  an  instantaneous  picture  cf 
system  resources.  The  system  was  likely  restructuring 
memory  tc  accommodate  the  increased  workload  when  the  deci¬ 
sion  was  made  to  detach  all  remote  users.  [Ref.  22:  p.  5-2] 

Another  operational  contribution  to  poor  network  perfor¬ 
mance  occurred  when  FT S  was  used  to  transfer  files  arcur.d 
within  the  same  site,  as  opposad  to  using  a  COPY  utility. 
Transferring  a  file  with  sending  and  receiving  sites  speci¬ 
fied  as  the  same  site,  sends  the  file  to  the  local  IMP  which 
immediately  returns  the  file  to  the  same  host.  During  IVY 
LEAGUE  82,  exercise  statistics  showed  that  3«S  of  all  file 
transfers  at  the  NHCC  were  same-site  transfers,  as  were  67% 
cf  Military  Airlift  Command  (MAC)  transfers  and  83%  at  "he 
WWMCCS  site  supporting  the  Ccmtander-in-Chief ,  Naval  Forces 


Europe.  C8«*-  22:  p.  5-3)  This  type  of  functional  misuse 
wastes  host  systea  resources  and  contributes  to  win  loading. 
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I.  BBCOBBBM PATTONS  £ND  COMCLOSIOHS 


When  the  current  WWMCCS/WIN  management  problems  are 
addressed  during  the  modernization  phase,  network  perfor¬ 
mance  should  improve.  This  will  decrease  user  frustration, 
especially  during  high  volume  times,  and  increase  user 
activity  cn  the  system.  This  increase  in  volume  in  turn, 
may  affect  system  performance  and,  with  greater  user  parti¬ 
cipation  comes  additional  site- unique  software.  Site-unigu* 
applications  are  created  due  to  deficiencies  within  the 
system  which  will  always  exist  in  a  system  as  large  as 
WWMCCS.  The  WIS  modernization  plan  does  not  propose  to 
eliminate  this  unigue  category  of  WWMCCS  software,  just 
minimize  its  proportion  to  standard  software. 

A.  SOFTWARE 

The  WIS  modernization  plan  includes  a  new  operating 
system  release,  GCOS  8.0,  and  a  modified  Honeywell  main¬ 
frame,  the  H6000  Distributed  Processing  system  (DPS). 

The  major  software  modifications  include: 

(1)  improved  data  management  and  timesharing 
processing 

(2)  DPS  software  written  in  a  high  order  language 
which  facilitates  maintenance  and  modifications 

(3)  increased  number  of  timesharing  users  from  200 
tc  600 

(4)  increased  number  of  concurrent  processes  from  64 
tc  511  [Ref.  23] 

Net  mentioned  in  the  WIS  modernization  plan  is  any  just¬ 
ification  that  this  increase  in  possible  user  activity  will 
cot  further  degrade  system  performance.  Although  a  new 
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processor  is  under  consider ation,  the  H6000  DPS  mcdif lec¬ 
tion,  a  significant  increase  in  processing  capability  is 
already  critical  to  maintain  availability  of  present  WWMCCS 
software.  Increasing  the  number  of  time  sharing  users 
three-fold  will  cuickly  comsume  any  available  processing 
time. 

The  S w rices  mederniza tion  plan  also  includes  the  EM4 
software  package  for  tetter  file  management,  allowing  diffe¬ 
rent  file  structures  for  files  in  the  same  data  base,  ar.d  an 
enhanced  DBMS,  the  Integrated  Data  Store  II  (IDS  II).  with 
the  current  IDS  I,  the  progammer  is  not  independent  cf  the 
data  tase  --  one  of  the  fundamental  requirements  cf  a  Data 
Ease  Management  System.  When  using  IDS  I,  the  user  must 
know  the  data  base  layout,  referred  to  as  the  schema,  ar.d 
must  include  various  system  routines  to  successfully  update 
the  data  tase.  IDS  II  will  be  more  of  a  true  DBMS,  allowing 
user  independence  frem  the  data  base  schema. 

With  a  true  DBMS,  more  users  are  likely  to  pursue  infor¬ 
mation  contained  within  the  system,  thus  increasing  user 
retrievals  from  remote  sites,  i.e.,  retrieval  requests  from 
the  JDS,  and  increasing  data  transfers  on  WIN.  Again,  the 
WIS  modernization  plan  lacks  an  apparent  knowledge  cf  hew  to 
handle  this  increase  in  activity. 

Although  the  basic  software  design  of  the  WWMCCS  equip¬ 
ment  is  inadequate  fer  a  Multi-Level  Security  (MLS)  system, 
there  has  been  a  proposal  using  hardware  modifications. 
Honeywell  has  developed  a  system,  the  Honeywell  secure 
Communications  Processor  (SCOMP)  ,  which  runs  on  the 
Honeywell  Level  6  minicomputer  and  is  billed  as  a  MLS 
system.  SCOMP  utilizes  four  rings  of  protection  with  the 
kernel  residing  in  Ring  0  and  the  least  priviledged  riro. 
Ring  3,  belonging  to  the  users.  3ut  SCOMP  also  modifies  the 
hardware  by  supplying  a  hardware  segmentation  capability  for 
dividing  main  memory  into  distinct  logical  (not  physical) 
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areas.  This  should  allow  access  checking  per  segment  fcr 
rsad/write  priviledges,  thus  maintaining  controlled  software 
sharing  among  many  users.  (Ref.  24:  p.  4] 

While  SCCMP  has  net  been  fully  validated  by  the  DOD 
Computer  Security  Center,  part  of  the  National  Security 
Agency  (NS&) ,  it  is  considered  a  large  step  towards  the 
secure,  time-shared  computer  resources  needed  in  communities 
such  as  the  WWMCCS  community.  In  December  1961,  the 
security  center  published  a  Product  Evaluation  Bulletin 
specifying  that  SCOMf  "...  should  be  considered  an  accep¬ 
table  candidate  for  a  wide  range  of  minicomputer 
applications  which  require  an  enhanced  architecture  to 
support  secure  processing  requirements."  [Ref.  25] 

Another  emerging  alternative  is  the  ELACKER  Technology. 
BLACKER  will  supply  end-to-end  encryption  through  the 
ELACKER  Terminal  Access  System  (TAS)  .  This  TAS  is  a  PDF 
11/70  or  PDF  11/34  and  acts  as  a  buffer  between  the  network 
and  hest  computers  fcr  security  verification.  Upon  lcg-cn, 
each  user  will  be  assigned  a  one  time  key  for  the  life  of 
the  terminal  session.  These  keys  will  be  checked  and  veri¬ 
fied  before  access  tc  each  data  base  is  allowed.  They  will 
also  be  used  to  control  inadvertent  raisr outing  of  data, 
referred  to  as  spillage.  [Ref.  26:  p.  6  ] 

The  main  idea  behind  the  ELACKER  prototype  is  tc  allev¬ 
iate  the  burden  cf  numerous  passwords  for  each  user  per  each 
host  computer.  Passwords  are  no  longer  considered  secure 
for  seme  classification  levels  because  they  must  be  stored 
within  the  computer  system  and  users  frequently  violate 
security  procedures  by  writing  them  down.  One  of  the  most 
viable  alternatives  proposed  has  been  the  use  of  magnetic 
strip  identification  badges  and  electronic  badge  readers. 
This  system  would  allow  for  minimum  manual  intervention. 
[R®f.  26:  p.  17] 
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A  MLS  system  would  allow  the  Joint  Deployment  Agency  to 
control  access  tc  various  capabilities  in  specific  CFLAMs. 
Presently,  all  host  computers  and  personnel  oust  be  cleared 
to  the  highest  security  level  of  any  piece  of  data  contained 
in  the  oelan . 

Functioning  without  a  MLS  system,  full  utilization  cf 
WWMCCS  resources  is  improbable  and  the  sharing  cf  computer 
resources  over  the  network  is  restricted.  During  the 
interim  between  the  present  security  procedures  and  the 
eventual  development  cf  a  MLS  system  for  WWMCCS,  the  *15  JPM 
becomes  the  central  WWMCCS  security  officer  to  standardize 
physical  security  procedures  and  set  guidelines  or.  the 
handling  cf  different  security  levels  on  the  same  machine. 

B.  HABDB1RE 

The  wis  modernization  plan  does  not  address  the  issue  of 
redundant  power  supplies.  The  vulnerability  of  computer 
hardware  to  electric  power  for  operations  ar.d  support,  i.  e. , 
air  conditioning ,  is  immense,  with  very  few  WWKCC 3  nodes 
having  a  reliable  backup  power  source,  the  network  should 
not  be  considered  survivable. 

Included  in  the  rear-term  WIS  modernization  program  is 
the  procurement  of  the  Honeywell  6000  Distributed  Processing 
System  (DFS)  modification.  The  H60QO  DPS  offers  major  hard¬ 
ware  and  software  improvements  over  the  H6060  and  H6080 
equipment  currently  used  in  the  WWMCCS  community.  Major 
hardware  changes  include: 

(1)  70%  to  90%  increased  processing  speed 

(2)  space,  ocwer,  and  air-conditioning  requirement 
reduct  ions 

(3)  three-ring  architecture  for  MLS  system  possi¬ 
bility  [Bef.  23] 
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The  Honeywell  mainframes  presently  used  are  fast 
approaching  the  age  cf  computer  antiquity.  The  largest 
problem  centers  arourd  the  Honeywell  architecture  which  was 
not  designed  to  support  an  online,  interactive  environment. 
Hhen  hardware  replacement  is  considered,  the  MWNCCS  host 
computers  should  be  replaced  with  computer  systems  designed 
to  support  a  real-time,  online,  interactive  environment. 

The  changing  requirements  for  network  software,  moving 
this  software  onto  the  Datanet  processors,  ar.d  advancements 
in  computer  technology  have  all  reduced  the  mainframe 
requirements  for  most  WWHCCS  sites.  For  hardware  acquisi¬ 
tion,  WWMCCS  sitss  will  consider  a  series  of  minicomputers, 
for  instance  the  Honeywell  Level  6  minicomputers,  versus  one 
large  machine.  Of  course,  each  site  would  be  unique  in 
configuration  but  a  typical  WWJICCS  site  could  employ  one 
Level  6  for  each  of  the  following  functions:  t.ie  AJTCDTN 
message  processing,  the  MIN  connection  to  include  handling 
TLCP  support,  the  AD  FLO  functions,  and  all  resident  data 
bases  and  local  processing  requirements. 

C.  CCHHDNIC1TIONS  PROCESSOR 

The  MMHCCS  community  has  communications  processor  moni¬ 
toring  software  which  consumes  2,500  words  ct  Datanet  memory 
when  implemented  but  can  supply  valuable  information  or. 
Datanet  overload  situations.  The  implementation  of  this 
monitoring  software  for  the  Datanet  is  not  a  requirement  for 
MIN  sitss,  tut  each  site  should  perform  a  trade-off  analysis 
on  memory  required  and  information  received.  The  statis¬ 
tical  output  from  the  monitoring  software  could  reduce 
Datanet  reboots  by  notifying  operators  of  potential  weak¬ 
nesses  in  the  system;  i.  e. ,  running  out  cf  buffer  space  for 
message  processing  or  the  number  of  transfer  denials 
exceeding  an  acceptable  level.  If  memory  space  cannot  be 
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supplied  during  a  crisis/exercisa  situation  for  the  moni¬ 
toring  software,  controlled  simulations  using  the  Octir.  =  *. 
monitoring  software  should  be  implemented  tc  forecast  poten¬ 
tially  threatening  process  combinations  to  the  Datanet. 

A  set  of  standard  system  guidelines  should  be  developed 
for  use  at  nil  WIN  sites  to  establish  acceptable  criteria 
for  Catanet  reboots.  Frequent  rebooting  as  a  first  try  at 
solving  a  network  problem  shculd  oe  discouraged. 

Also,  a  WIN  software  validation  package  shculd  be  devel¬ 
oped  tc  prohibit  file  transfers  within  the  sate  site. 
Included  shculd  be  installation  checks  to  insure  WWMCCS 
Standard  System  Software  is  installed  properly  and  site 
options  are  set  at  the  prescribed  level.  [Bef.  22:  p.  7-4] 

The  Catanet  cverconf igu ration  problem,  i.e.,  115  termi¬ 
nals  linked  to  one  Datanet  at  JD  A ,  lends  itself  to  tvc 
reco m aendaticns.  The  first  solution  is  simple  but  rather 
expensive  --  procure  more  Honeywell  Datanet  355  nrocesscrs. 
Ideally,  this  would  allow  one  Datanet  to  be  dedicated  tc 
that  site's  him  connection.  This  configuration  would  reduce 
71 N  problems  associated  with  operator  reboots  cf  the  Datanet 
to  solve  ncr.-WIN  problems.  [Ref.  22:  p.  2-2]  With  addi¬ 
tional  Datanets,  user  load  could  be  better  distributed  and 
Datanet  failures  would  have  less  impact  on  the  site  perfor¬ 
mance.  At  a  minimum,  sites  should  avoid  linking  high  volume 
connections  such  as  KIN,  AUTODIN,  and  the  JCS  A Dr  Liason 
Officer  ( AD  FLO)  terminals  on  the  same  Datanet.  In  addition, 
sites  should  adhere  tc  the  standard  WWMCCS  loading  levels 
for  the  Catanet  as  directed  by  the  WWMCCS  ADP  Advisory 
Kemorandum  (WAAH). 

The  second  r ecomaendation  is  to  eliminate  the  Honeywell 
communications  processor  equipment  and  transfer  these  func¬ 
tions  either  to  another  vendor  communications  processor  or 
tc  a  minicomputer,  such  as  the  Honeywell  Level  6  minicom¬ 
puter.  The  Honeywell  Datanet  355  is  limited  in  a  memory 
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sizs  which  is  no  longer  sufficient  for  the  normal  message 
processing  capacity  at  large  WIN  sites.  Using  the  Level  6 
ainiccaputer  in  series  would  alleviate  the  aeaory  problems 
and  provide  additional  processing  capabilities. 

D.  HETWCBK  FRAGMENT ATIQN 

Tc  prevent  the  reoccurrence  of  problems  similar  to  the 
cr.es  caused  by  the  Master  IMP  being  reconfigured  during  IVY 
LEAGUE  82,  contingency  plans  should  be  devised  to  eliminate 
the  drastic  configuration  changes  as  were  necessary  when 
such  a  targetable  IMF  was  deleted  from  the  network.  Studies 
and  crisis/exercise  sent  ter  ir.g  should  be  undertaken  to 
predict  possible  circuit  or  IMP  links  which  could  initiate 
network  fragmentation.  [Ref.  22:  p.  3-9]  After  identifying 
these  areas,  they  should  be  reinforced  during  high  volume 
times  ty  redundant  configuration  or  specific  rerouting 
algorithms. 

After  the  C/30  switch  upgrade,  part  of  the  wwmccs  moder¬ 
nization  plan,  IMP  and  circuit  outages  should  decrease.  The 
C/30  switch  will  provide  tandem  processing  of  up  to  300 
packets  per  second,  fer  a  total  of  900  packets  being 
processed.  Routing  and  rerouting  will  be  accomplished  by 
adaptive  routing  algorithms  which  will  reroute  individual 
packets  tc  the  shortest  path.  In  addition,  i _• itoring  and 
control  functions  are  included  to  provide  fault  isolation 
and  hardware  and  software  problem  diagnosis. 

Replacing  the  huge  WWMCCS  network  with  a  series  of  Local 
Area  Networks  (LANs)  will  alleviate  some  of  the  degradation 
felt  during  network  fragmentation.  Moving  the  network  soft¬ 
ware  from  the  Honeywell  mainframes  onto  the  Datanets  is  the 
first  step  in  building  independent  LANs.  Eventually,  all 
network  software  should  be  moved,  alleviating  t n=  mainframe 
from  any  network  control  responsibilities.  This  wcuid 
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remove  the  restriction  for  standard  hardware  for  all  win 
sites.  With  no  standard  hardware  li mirations,  users  could 
tailor  the  acquisition  of  new  hardware  around  specific  sire 
requirements.  Since  all  host  systems  will  be  linked  through 
a  common  network,  minimum  compatibility  problems  should  be 
experienced . 

E.  B ISO 0 BCE  COHTESTIOH 

One  popular  reccm mendat ior.  for  the  mainframe  processor 
contention  problem  is  the  addition  of  another  processor  fcr 
the  NMCC  Readiness  System.  This  additional  processor  would 
be  justified  during  an  exercise  but  not  fully  utilized 
during  daily  operations. 

As  opposed  to  procuring  an  additional  processor,  ‘he 
Support  System  could  be  modified  to  temporarily  provide  the 
necessary  h araware/scftw are  equipment  during  crisis/exercise 
situations.  The  nair  advantage  to  this  plan  is  reduced 
swapping  for  CPO  contention.  [Ref.  22:  p.  4-3]  The  validity 
of  this  plan  is  somewhat  questionable.  Previous  to  the  NMCC 
WWMCCS  computer  system  division  into  Headiness  and  Support 
systems,  there  was  *  H6080  machine  with  two  processors.  C?fJ 
contention  reached  a  level  to  warrant  the  separation  cf 
production  and  development  efforts,  thus  was  born  another 
computer  system  strictly  for  developmental  efforts. 

Conf iouraticn  now  stands  at  two  separate  systems  with  cne 
processor  each.  As  mentioned  in  a  previous  section,  users 
do  not  always  respect  the  guidelines  for  use  cf  these  twc 
systems.  In  light  of  user- induced  problems  affecting 
performance,  stronger  enforcements  of  implemented  procedures 
would  be  tore  cost-effective.  The  recommendation  fcr  an 
additional  processor  is  expensive  whether  the  dollars  are 
spent  actually  procuring  another  processor  which  will  be 
fully  utilized  only  about  twenty-five  percent  of  the  time  or 
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the  Support  System  software  is  used  for  high- priority  usage. 
During  the  later  option,  numerous  software  development 
personnel  with  no  planned  participation  in  a  crisis/exercise 
environment,  would  be  without  a  computer  processor  which 
greatly  restricts  their  developmental  efforts. 

Also  hindering  processor  performance  is  the  Honeywell 
urgency  scheme  for  processes.  The  basic  idea  of  the 
Honeywell  urgency  schere  is  acceptable.  The  urgency  scheme 
needs  adjusting  and  the  implementation  should  be  modified 
for  tighter  controls  on  the  system  console  operator's 
ability  tc  override  the  system  default  urgencies.  Also, 
enhancements  to  prohibit  application  software  from  reaching 
urgencies  in  the  WIN  software  level  is  necessary.  This 
would  discourage  resource  competition  and  improve  system 
slowdown.  One  urgency  system  recommended  included  net 
allowing  any  application  software  to  exceed  ar.  urgency  of 
10.  Few  users,  mostly  system  programmers,  would  c  ierat«  at 
urgencies  cf  30  to  4C  and  no  users  would  exceed  40.  This 
proposal  leaves  urgencies  of  40  to  63  for  system  software 
and  WIN  software. 

A  new  TSS  Monitor  has  been  developed  within  the  WWMCCS 
community.  This  monitoring  software  is  easy  tc  use  via 
system  console  commands  and  no  system  interruption  is  exper¬ 
ienced.  Unfortunately,  this  new  Monitor  was  not  operational 
for  IVY  LEAGUE  92;  but  it  can  be  utilized  during  the  next 
exercise  for  selected  small  periods  of  time  to  allow  a  more 
thorough  analysis  of  slowdown  periods.  (Hef.  22:  p.  4-4] 
With  the  WIS  modernization  plan,  the  capability  to  monitor 
each  network  element  is  achieved  through  the  Monitoring 
Centers  cf  the  DDN.  DDN  will  also  provide  an  automatic 
fault  recognition  and  isolation  for  trouble  spots  with  most 
reconfigurations  being  handled  without  dedicated  personnel. 
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aiN  software,  such  as  the  memory  management  algorithms 
for  FIS  and  TELNET,  should  be  redesigned  to  reduce  -he  allo¬ 
cation  and  deallocation  processing  for  aemory.  Or.e 
alternative  could  be  a  ainiaum  size  of  aemory  allowed  for 
allocation,  this  would  eliminate  the  overhead  generated  ir 
the  swapping  of  IK. 

Additionally,  improved  operational  procedures  are  needed 
concerning  teleccnf e xsncing  transcript  files.  Options  avai¬ 
lable  include; 

(1)  spooling  the  printed  output  with  a  lower  urgency 
which  would  force  printing  at  less  critical  tiaes 

(2)  allowing  printing  of  the  transcript  file 
requests  only  during  scheduled  time  periods 

The  resource  contention  problem,  especially  at  the  N“CC, 
is  stated  as  a  top  priority  of  the  HIS  modernization  plan; 
however,  no  tangible  alternatives  have  been  proposed. 

F.  JES  BFSCOBCS  CONTENTION 

The  memory  chasing  problems  of  the  JDSIP  and  JDSUP 
subsystems  may  be  approached  from  several  alternatives. 
Cbvicusly,  the  aiount  of  al loca tion/deallocaticn  depends 
almost  entirely  on  the  idle-time  of  the  subsystem.  Studies 
should  be  conducted  at  each  site  supporting  the  Remote 
User’s  Package  (ROP)  to  determine  rts  use/idle  ratio.  If 
the  JESIF  subsystem  remains  in  memory  the  majority  cf  the 
time,  minimum  overhead  is  generated.  If  the  JDSIP  usa/idle 
ratio  is  small,  significant  overhead  will  be  generated  ty 
the  subsystem  changing  urgencies  to  engage  placement  in  cere 
and  the  chance  of  checking  for  transaction  activities.  An 
alternative  would  be  the  development  of  a  small  check- 
routine  tc  permanently  reside  in  primary  memory.  Its  job 
would  be  to  periodically,  every  two  to  three  seconds,  check 
for  incoming  transactions  and  change  the  JDSIP  urgency  to  51 
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if  transactions  are  available  for  processing,  at  the  same 
time  changing  its  owr  urgency  to  zero.  This  would  produce  a 
sleep  state  similar  to  that  of  the  JDSIP  when  inactive,  only 
the  check-r  cutine  would  not  leave  core.  Hhen  the  JDSIP 
finished  the  necessry  transaction  processing,  it  would 
decrease  its  urgency  to  zero  and  change  the  check-routine 
urgency  tc  51.  This  would  allow  the  JDSIP  to  be  swapped  to 
mass  storage  at  the  next  memory  request  and  the  check- 
routine  wculd  have  high  priority  for  processor  time  and 
resume  waiting  for  the  next  transaction. 

Another  alternative  to  be  considered  is  the  permanent 
allocation  cf  28K  to  the  JDSIP.  This  would  allow  the  JDSIP 
permanent  residence  in  primary  memory  and  is  feasible  if  the 
host  system  is  not  memory-restricted. 

The  JDSUP  subsystem  remains  in  primary  memory  itself  at 
9K  but  periodically  requires  an  addition  50K  for  processing. 
Fart  cf  the  problem  concerning  the  JDSUP  memory  allocation 
stems  from  the  JES0P  requiring  one  single  block  cf  5 OK  cf 
memory.  Generally,  the  system  must  rearrange  memory  tc 
create  a  contiguous  50K  block.  The  easiest  solution  wculd 
be  the  permanent  attachment  of  the  50K  to  the  JDSOF 
subsystem.  For  a  system  memory-restricted  at  all,  this 
alternative  is  impractical.  A  more  feasible  alternative 
would  be  to  include  50K  in  the  system  size  for  the  JDSUP  and 
treat  the  59K  as  one  system.  Then  modify  the  JDSUP  to 
reside  on  mass  stoarga  and  utilize  a  check-routine,  similar 
to  the  JDSIP,  for  dynamic  checking  of  requirements.  The 
same  urgency  swapping  and  processing  schemes  could  be 
utilized. 

Ir.  addition  to  the  specific  modifications  to  the  JDS 
subsystem,  several  other  measures  could  be  taken  tc  improve 
BIN  resource  requirements: 

(1)  development  cf  standards  for  new  application 
software 
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1 2)  standard  criteria  for  resource  requirements  in 

nee  software 

(3)  code  optimization  and  memory  overlays  fcr  larger 

systems 

(4)  utilization  of  data  compression  techniques 

(5)  improved  input/output  interfaces 

(6)  more  efficient  data  transaction  activites 

(7)  elimination  of  large  data  transfers 

G.  CONCLUSIONS 

Cne  of  the  largest  problems  with  the  Defense  Data 
Network  (DDN)  will  be  the  Multi-Level  Security  issue,  with 
the  variety  of  users  linked  through  one  common  network,  a 
KLS  system  will  te  imperative. 

Another  DDM  concern  is  the  standard  data  communications 
protocols.  These  protocols  should  not  only  interface  with 
the  WWMCCS  sites,  but  should  be  able  to  interact  with  NATO 
systems  for  greater  interoperability.  The  WIS  J?M  presently 
intends  tc  require  standard  protocols  be  written  in  the  new 
COD  design  language,  ADA.  While  no  ADA  compiler  has  been 
fully  certified  as  meeting  all  DOD  standards,  the  step 
towards  standard  software  should  begin  at  software 
conception. 

The  WIS  modernization  plan  will  bring  modern  software 
and  later  hardware  into  the  WWMCCS  community.  The  WIS  JPM 
strategy  is  to  tackle  the  software  problems  in  WWMCCS  first 
and  bypass  the  fast  icving  technology  field  of  hardware 
until  later.  Not  all  of  the  WWMCCS  standard  software  needs 
rewriting  and  by  modernizing  the  software  first,  the  WWMCCS 
network  will  become  more  adept,  to  present  day  requirements. 

WWMCCS  ADP  problems  will  not  be  solved  by  the  WIS  moder¬ 
nization  plan  or  hardware  changes  alone.  The  WWMCCS 
computer  systems  are  used  for  war-gaming  ana  software 
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development  but  the  primary  intention  of  this  C3  system 
surfaces  during  crises  with  the  handling  of  message  traffic. 
The  heart  of  the  WHHCCS  ADP  prograa  must  be  a  fast,  reliable 
and  secure  transaction  processing  system.  Paster  routing 
algorithms  must  be  developed  and  iaproved  physical  surviv¬ 
ability  is  critical.  Now,  every  node  on  the  WWKCCS  network 
is  vulnerable  to  easy  destruction  and  each  node  lost  has  a 
great  impact  on  total  systee  performance. 

The  K1S  ecde  inization  plan  with  an  iaproved  DBMS, 
management  and  security  procedures,  and  user  interface  is  a 
significant  start  towards  the  remodeling  of  WSMCCS.  The 
modernization  is  planned  over  a  ten  year  period  and  a  major 
concern  will  be  maintaining  service  dollar  support. 

The  Joint  Deployment  System  will  certainly  benefit  from 
the  WIS  modernization  plan.  Eut  the  areas  of  network 
mana geme-rt,  multi-level  security,  and  resource  contention 
must  be  addressed  by  the  modernization  plan  and  alternatives 
prcpcsed.  In  the  meantime,  the  Joint  Deployment  agency  will 
continue  to  develop  JCS-unique  software  to  supplement  WlihCCS 
capabilities  and  provide  deployment  information  through 
crisis  situations. 
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